[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 <email@example.com> 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 for > | 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 placeholder > | positions in the body text of the article. > | I don't know what the form of those placeholders would need to be, open > | 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 <supplement>ary > | data could also be viewed in some kind of generic hierarchical mode, with > | 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. Thanks Doug