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: DocBook supplement and Netscape9? [was: DocBook and DITA]

On Thursday 21 July 2005 03:25, Kurt Cagle wrote:
> I've been following this thread for a while, and thought I'd throw this
> out.
> I'm the lead architect for the next version of Netscape, and am hoping 
> move the browser beyond the traditional role as an HTML viewer into a 
> generalized XML viewer. One notion that I've been toying with has been 
> integrate either DocBook or DITA support (or both) into the 9.0 browser,
> due out in 2007, and would be interested in hearing from the people on 
> list both what you think of this and what aspects of either or both
> standards we most specifically need to emphasize in order to make these
> formats useful to the general populace as well as to specialized users.

While you're in a throwin' kinda mood ...
This'd come under the heading of specialised use.

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/ )
  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?). 

Secondly it would also be nice to be able to take something akin to the 
DocBook Website autolayout.xml file, describing all articles in a given 
journal issue or topic map, an olink.xml database (or connection to such) 
and the raw XML DocBook <article> and format that with a hierarchical 
table of contents.
The aforementioned embedded collapsible <supplement> hierarchy would 
appear at the end of the article body.

Thirdly, it would be important to be able to XSLT transform this 
<supplement>ary data in other ways, for instance to provide input for 
other validation, evaluation or visualisation software.

For the moment this could be done server side as a once off to XHTML, but 
I'm not sure about the best way of handling such (hypothetical) 
<supplement>ary data in that case. In theory, serving raw XML articles 
with embedded supplements is the future right?

I guessed that a generic data container within an already well supported 
documentation container might actually get broad software/community 
support, but is it doable? Barking up the wrong tree?


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