Re: inheritance and encapsulation in xslt? / xslt for

Play the video

Subject: Re: inheritance and encapsulation in xslt? / xslt for xlink?
From: Howard Stearns <stearns@xxxxxxxxxxxx>
Date: Tue, 22 Jul 2003 14:27:54 -0400

David.Pawson@xxxxxxxxxxx wrote:

Just picking up one point Howard;

You intimate that you need to process  instances from n schema's
and hope to do it in a single stylesheet (or small group of stylesheets),
since all these schema's are derived from xbrl.

Correct. For example, suppose you (or Mr. Walsh) has invested in some stylesheets for DocBook. You want to be able to use them for instance documents for AcmeCorpDocBook, AcmeCorpHardwareDocBook, and MyDocBook. If these progressive layers only have a few new elements, that's ok. You can create new stylesheets to handle the difference. As Walsh says (as I recall), "If you make extensions to DocBook, it's not DocBook anymore."

Being able to directly reuse DocBook stylesheets on extensions is like saying that extensions are still DocBook. For What It's Worth, XBRL does say that extensions are still XBRL. That's the philosophy they're taking. I'm trying to unravel the consequences of this for XSL.


As a generality, I've always taken the starting point
that there is a one to one mapping, ...
I.e. change the schema and a new stylesheet is required.
I'm now curious if others adopt this as a starting point?

IBM did want to take the directly reusable stylesheet approach in the documentation domain. (Their reasoning is at http://www-106.ibm.com/developerworks/xml/library/x-dita1/index.html) However, I don't know if this was for real use or for a "science project".

For what it's worth, my reasoning in wanting to have directly reusable stylesheets is to allow early validation of large numbers of new specialized schemas by reusing the XSL-based validation for the more general schemas. (Even before anyone get's around to writing validation suites for the unique part of the specialization.) I'd also like third parties to write XSL-based tools (e.g., for display) based on general schemas, and have them still work (although not be specialized) for the thousands of more specialized schemas.

I imagine this kind of thing would be useful in a fair number of cases, but would not be commonplace amongst the bulk of XSLT use everywhere. E.g., I never had to do this kind of thing before, although it would have helped me slightly (not hugely) if I could have extended DocBook without so much cut and paste.

XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list

Current Thread
RE: inheritance and encapsulation in xslt? / xslt for xlink?, (continued) Robert Koberg - Mon, 21 Jul 2003 23:17:17 -0400 (EDT) Jeni Tennison - Tue, 22 Jul 2003 04:17:52 -0400 (EDT) Howard Stearns - Tue, 22 Jul 2003 14:29:52 -0400 (EDT) David . Pawson - Tue, 22 Jul 2003 04:58:55 -0400 (EDT) Howard Stearns - Tue, 22 Jul 2003 14:27:58 -0400 (EDT) <=

<- Previous	Index	Next ->
RE: inheritance and encapsula, David . Pawson	Thread	Precompiling Xpath expression, Venkateshwar Bommine
Hi ... brand new to list ... , David TROGDON	Date	Re: inheritance and encapsula, Howard Stearns
	Month

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Subscribe in XML format

RSS 2.0
Atom 0.3

XML Editor - Download a 15 Day Free Trial Now >

See What's New in Stylus Studio >

Buy Stylus Studio - XML Editor - Now >