Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove necessity of including profiling PI to enable profiling #529

Closed
ghost opened this issue Oct 28, 2019 · 5 comments
Closed

Remove necessity of including profiling PI to enable profiling #529

ghost opened this issue Oct 28, 2019 · 5 comments

Comments

@ghost
Copy link

ghost commented Oct 28, 2019

Currently, when you start a new document and want to enable profiling, you have to remember the following steps:

  1. Use a profiling attribute in your DC file or DAPS command-line invocation.
  2. Add a profiling attribute to the elements you want profiled.
  3. Add the profiling PI to the beginning of your document.

Imo, step (1) and (2) are relatively obvious. However, step (3) is non-obvious and has been an issue for me on a couple of occasions.

There does not seem to be a real justification for (3) to exist either -- if the DAPS command-line/or DC includes a profiling command, it is clear that the user intention is to profile. To get the right profiling stylesheet (DB4 v/ DB5), you only need to look at the xmlns & version attributes (or the DOCTYPE for DB4) -- and DAPS already does that for validation.

So, I would suggest to do the following:

  • enable profiling whenever there is a PROF* attribute either via command-line or DC file
  • find out which profiling stylesheets to use via xmlns/version attributes and DOCTYPE
  • remove recognition of profiling PIs, to simplfy the code (unless there is a good reason to keep this complication)
@tomschr
Copy link
Collaborator

tomschr commented Oct 28, 2019

I would like to address this issue a bit further:

find out which profiling stylesheets to use via xmlns/version attributes and DOCTYPE

That means, we need to find out first which DocBook version we use. For this use case, we have the daps-xslt/common/get-docbook-version.xsl stylesheet. Once applied to a XML file, it returns 5 (if the document is DocBook 5), 4 (some incarnations of DocBook 4.x), or 0 (zero, not a DocBook document at all).


Not sure if this is "simpler", but just for the records. I've compiled an almost equivalent output with xmlstarlet.

  • For DocBook 5:

    $ xml sel -N d=http://docbook.org/ns/docbook -T -t -v "/d:*/@version" XMLFILE
    

    Return the DocBook version. If you prefer true/false values, use this:

    $ xml sel -N d=http://docbook.org/ns/docbook -T -t -v "/d:*/@version or namespace-uri(/*)= 'http://docbook.org/ns/docbook'" XMLFILE
    
  • For DocBook 4:

    $ xml sel -T -t -v "appendix or article or book or bridgehead or chapter or colophon or dedication or glossary or index or lot or preface or reference or refentry or refsect1 or refsect2 or refsect3 or refsection or sect1 or sect2 or sect3 or sect4 or sect5 or section or set or simplesect or toc"  XMLFILE
    

    Returns true or false.

@fsundermeyer
Copy link
Member

DAPS already used said stylesheet and knows what DocBook version is used. Therefore the decision which profiling stylesheet to use can be done by DAPS internally.

@fsundermeyer
Copy link
Member

fsundermeyer commented Feb 13, 2020

We have 7 different profiling stylesheets:

  • docbook41-profile.xsl
  • docbook42-profile.xsl
  • docbook43-profile.xsl
  • docbook44-profile.xsl
  • docbook45-profile.xsl
  • docbook50-profile.xsl
  • docbook51-profile.xsl

Is it really necessary to have all of them (they differ, if at all, only slightly)? If we are to get rid of the PI, we need to reduce the stylesheets to two: one for DB4 and one for DB5.

@tomschr
Copy link
Collaborator

tomschr commented Feb 13, 2020

With sunsetting Novdoc and the need for a DTD, we can probably remove some. I would vote to keep docbook45-profile.xsl and docbook51-profile.xsl.

fsundermeyer added a commit that referenced this issue Jan 18, 2022
* profiling does not work, yet (needs fixing #529)
* renamed ADOC_DIR to ADOC_RESULTDIR for consistency

Requires to specify a custom directory where the topic files
are located. This should also be supported for xml and adoc for
consistency. All directories variables used in make should also
have the same name everywhere, regardless of the source format.
Will require a major code overhaul.
fsundermeyer added a commit that referenced this issue Mar 2, 2022
Profiling nos is enabled automatically if one of the profiling variables
is set or when the option --setdate is used
@fsundermeyer
Copy link
Member

Fixed with f106e07

fsundermeyer added a commit that referenced this issue Mar 23, 2022
Profiling nos is enabled automatically if one of the profiling variables
is set or when the option --setdate is used
fsundermeyer added a commit that referenced this issue Oct 20, 2022
Profiling nos is enabled automatically if one of the profiling variables
is set or when the option --setdate is used
fsundermeyer added a commit that referenced this issue Oct 25, 2022
Profiling nos is enabled automatically if one of the profiling variables
is set or when the option --setdate is used
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants