OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

docbook message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [docbook] RFE/RFC: Include format Attribute in DocBook Schema?


Hi,

IMO there's already the profiling mechanism to have conditional elements:

http://www.sagehill.net/docbookxsl/Profiling.html

I think it's enough for elements used for a specific format. It's what I use to tweak PDF and HTML outputs.

Regards,
BG

On Sun, 03 Jun 2012 10:53:01 +0200, Thomas Schraitle <tom_schr@web.de> wrote:

Hi,

the Common Effectivity Attributes[1] in TDG5.1 contains a lot of useful
attributes. However, IMHO, we don't have a way to express that an element
"belongs" to a specific (output) format only.

As such, I would propose to add such a "format" attribute to the DocBook
schema (in the following text I use "format" for simplicity reasons. If you
don't like it, feel free to suggest a different name like "outputformat",
"targetformat", or whatever you think is appropriate.)

I know the committee is hesitent to add additional attributes to the schema,
but I think it has several benefits. Here is why I think this is useful:

1. Currently, the DocBook stylesheets support several output formats. Probably
this list will grow in the future.

Dealing with such a variety of possible output formats makes it sometimes
harder to write in a "format independant" way. However, if someone really
wants to express that a certain element is only useful for PDF, the current
list of common attributes doesn't support this.

From a semantic point of view, no common effectivity attributes are suited for this task. By using a "format" attribute in combination with profiling, I can
distinguish such a case.


2. The current assembly schema contains in its <output/>[2] element a "format"
attribute (actually that's where this idea originated).

However, with the raise of assemblies and modules, output formats will become
much more important. From a usability point of view, having a consistent
"format" attribute in DocBook and in <output/> does make sense: users can
recognize that as the same "thing".


3. Adding "only" an attribute to the DocBook schema is not as intrusive than
adding a new element. :) The changes to the schema are minimal:

  db.format.attribute =
    ## Identifies the target format to which the element applies
    attribute format { text }

  db.effectivity.attributes =
     ...
     & db.format.attribute?
Of course, the profiling stylesheet needs to be changed as well. However,
apart from these two parts, no other changes are needed.

Unfortunately, after some further investigations, there is a problem: "format" is already occupied in db.common.data.attributes which is used by videodata, audiodata, imagedata, and textdata. So *if* you think this idea is useful, we
have to give it a different name anyway.

What do you think? Does anybody use documents which contain target specific
information in combination with profiling?



---- References
[1] http://www.docbook.org/tdg51/en/html/ref-
elements.html#common.effectivity.attributes

[2] http://www.docbook.org/tdg51/en/html/output.html





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]