[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 to > move the browser beyond the traditional role as an HTML viewer into a more > generalized XML viewer. One notion that I've been toying with has been to > 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 this > 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/ ) 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?). 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? Thanks Doug
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]