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] Re: DocBook supplement and Netscape9?

On Tuesday 26 July 2005 22:01, Norman Walsh wrote:
> / Doug du Boulay <ddb@owari.msl.titech.ac.jp> was heard to say:
> [...]
> | I've been wondering about the possibility of an embedded DocBook
> | <supplement>, to appear as the final element in a DocBook <article>,
> | <book> or <part>. This would provide a centralised collection point 
> | associated data in generic
> | external XML formats, such as:
> |
> |   XDF (http://xml.gsfc.nasa.gov/XDF/XDF_home.html )
> |   XSIL (http://www.cacr.caltech.edu/SDA/xsil/ )
> | or
> |   ESML (http://esml.itsc.uah.edu/ )
> |
> | The intention is that some of this supplementary data could be XSLT
> | formatted into, for instance, tables inserted at appropriate 
> | positions in the body text of the article.
> | I don't know what the form of those placeholders would need to be, 
> | for suggestions...
> | The default processing expectation would be to otherwise ignore
> | everything within the <supplement>ary data section. But for browsing
> | DocBook XML, (with Netscape!) it would be nice if the raw 
> | data could also be viewed in some kind of generic hierarchical mode, 
> | collapsible and expandable branch nodes (in the manner of XMLSpy?).
> Can you provide a concrete example of what you might want to put in
> supplement? It sounds like this is stuff that belongs in <info>, but
> I'm not sure I really understand what you want to put in there.

I personally would like to fill it with raw experimental data and its
associated derived results, marked up in a non-DocBook XML format. 
This would be the source data being discussed within the prose of the 
article. A lot of this data would be in the form of hierarchically 
organised lists of attributes and values of which a selection may need 
to be inserted into tables within the ultimately formatted article. 
The data selections and formatting of those tables would be specified
in stylesheets provided by third-parties, but may well be standardised 
for a particular domain/journal. That would all be outside the scope of 
DocBook which would only need to provide the terminal <supplement> 
element as a centralised repository with no further processing 
expectations. Default renderings to XSL-FO, pdf and ps and HTML would 
treat <xsl:template match="supplement"/> as a no-op. But a browser such 
as Netscape might be in a position to render such content in a more
appropriate way.

On the other hand, it could also contain such things as the overly 
verbose SVG and MathML data that might hinder the editing of an 
article, but could be referenced from within the prose and presumably 
identity transformed (i.e. coppied) and inserted where necessary in 
modes intended for reading.

I think <info> might be reserved for information about the article itself 
rather than the source data that inspire the writitng of the article.

Sorry, I don't have a real world example yet.


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