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: RE: [xslt-conformance] Issue regarding combinedcatalogue/documentationfile


I vote for 3.

-----Original Message-----
From: G. Ken Holman [mailto:gkholman@CraneSoftwrights.com] 
Sent: Thursday, April 25, 2002 11:54 AM
To: xslt-conformance@lists.oasis-open.org
Subject: Re: [xslt-conformance] Issue regarding
combinedcatalogue/documentation file


At 2002-04-25 11:59 -0400, I wrote:
>... 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.

Trying to implement (3) I've got a problem tracking the files that are 
necessary for a complete delivery.  I don't want to hardwire the merge 
process to XSLT, which means the merge invocation cannot have any
awareness 
of the documentation files.  But I cannot see any way around it.

Can we justify going back to (2)?  I don't think we can.

I think I'm obliged to add to the merge invocation batch file a 
"spec-specific section" that would be modified by another technical 
committee to refer to the documentation files in their environment.

Please comment if you have any opinions on this as I would like the
merge 
process to be turnkey.

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


----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>


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


Powered by eList eXpress LLC