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

 


Help: OASIS Mailing Lists Help | MarkMail Help

xslt-conformance message

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


Subject: [xslt-conformance] Issue regarding combined catalogue/documentationfile


Good morning, folks,

I've come across a situation where I need your input.

Up until now I have assumed that the supplied catalogue for our normative 
package would be one a single XML instance incorporating all of the 
submitters catalogues, all of our discretionary and other package-specific 
constructs, as well as all of the documentation constructs used to produce 
the resulting HTML.

In my prototype, the documentation constructs were posited to be abstract 
concepts and custom constructs that would mix without conflict with the 
rest of the catalogue stuff.  Not a problem, since the documentation 
constructs were custom.

Carmelo has posited, quite rightly, that the documentation instance could 
very well include HTML constructs, requiring the HTML DTD, which would 
conflict with our own constructs.

Taking this a step further, another committee using our environment would 
probably have very good reasons to use documentation constructs of their 
own that would conflict with ours.

Two ways we can go with this:

   (1) - abandon DTDs and go with RELAX-NG (another OASIS technology)
       - pro - all of the committee information delivered in a single instance
       - con - no RELAX-NG DTD for HTML and other committees may be reluctant
               to use RELAX-NG

   (2) - force users of our catalogue environment to create custom constructs
         and DTDs that supplement the constructs already defined in the
         catalogue DTD
       - pro - all of the committee information delivered in a single instance
       - con - other committees may be reluctant to create their own DTDs for
               documentation constructs

   (3) - separate the documentation constructs from the catalogue constructs
         in the delivery from our committee to the users of the test suite
       - pro - easy assimilation of documentation into the environment
       - con - all of the committee information delivered in two instances, not
               one, with the headache of not losing the file or not knowing
               where the file can be found when configuring the catalogue, etc.

I propose we go with (3) and abandon the idea that everything can be 
delivered in a single XML instance.

Please give me your comments.

Thanks!

...................... Ken

--
Upcoming: 3-days XSLT/XPath and/or 2-days XSLFO: June 17-21, 2002
-       : 3-days XML Information Modeling: July 31-August 2, 2002

G. Ken Holman                mailto:gkholman@CraneSoftwrights.com
Crane Softwrights Ltd.         http://www.CraneSoftwrights.com/s/
Box 266, Kars, Ontario CANADA K0A-2E0 +1(613)489-0999 (Fax:-0995)
ISBN 0-13-065196-6                      Definitive XSLT and XPath
ISBN 1-894049-08-X  Practical Transformation Using XSLT and XPath
ISBN 1-894049-07-1               Practical Formatting Using XSLFO
XSL/XML/DSSSL/SGML/OmniMark services, books(electronic, printed),
articles, training(instructor-live,Internet-live,web/CD,licensed)
Next public training:                  2002-05-06,07,09,10,13,20,
-                          06-04,07,10,11,13,14,17,20,07-31,08-05



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


Powered by eList eXpress LLC