[xsl] inheritance and encapsulation in xslt? / xslt for xlink?
Subject: [xsl] inheritance and encapsulation in xslt? / xslt for xlink? |
From: Howard Stearns <stearns@xxxxxxxxxxxx>
Date: Mon, 14 Jul 2003 13:32:58 -0400
QUICK SIMPLE QUESTION (that could avoid all that follows, below):
Where can I find examples of stylesheets designed to key off of XLink
arcs with transitive roles?
I want to have two XML Schemas, where one specializes some (but not all)
of the elements in the more general schema.
Meanwhile, I want to have two XSLT files:
One will work with instance documents of EITHER schema.
The second provides unique results for SOME of the elements in the more
specific schema, while many should be transformed in the same way as
corresponding elements in the general schema.
What are the general techniques for doing this? The specialized schema
may define hundreds of specialized element tags for which the general
XSLT behavior is unchanged, and I don't want to have to repeat the
definitions from the general XSLT with gratuitous name changes for the
xsl:template match attribute value.
I'm looking for an architecture or methodology that allows encapsulation
in that schema designers need only define those elements that are
different from the general model and need not be aware of XSLT
programming or existing XSLT code written for the general schema.
Meanwhile, writers of XSLT code should not have to change with every
change to the general XSLT or the general schema.
I want inheritance in my XSLT.
XBRL (http://www.xbrl.org/) defines taxonomies (schema) for financial
statement and other business reporting instance documents. Specialized
taxonomies are defined by reference to more general ones using XLink and
XML Schema. Links are defined with roles such as "general-special" and
"whole-part", though I do not fully understand this yet.
It's a lot of work, but not intractable, to define company-specific
schemas based on industry-specific schemas, which are in turn based on
more generic ones. However, I'm not sure how to manage a series of XSLT
that is meant work on instance documents of a large number of these
For the purpose of this question, let's assume that I can alter the
schema files (e.g., by adding "class" attributes) but that I should try
to avoid doing so.
I've written a lot of XSLT (1.0), but not within the last year.
I'm more familiar with DTD than with XML Schema.
I'm new at XLink, but familiar with RDF and related concepts.
I'm very familiar with the implementation guts of OO programming languages.
*** XSLT/XPath 2.0 makes use of XML Schema substitution groups, but:
- I'm under the impression that these can only be one level deep, not
a general inheritance chain as is required here.
- I'm under the impression that most XSLT engines don't implement 2.0.
*** IBM's Darwin Information Typing Architecture (DITA) seems to be what
I'm looking for. (See
The technique is to define a class attribute in the DTD/schema and then
write xsl:templates that match a portion of the value of the class
attribute. The effect is to hand-implement a "class inheritance list" as
though the schema elements were a prototype-based object-oriented
<!-- The DTD effectively defines something like this for a "subclass"
element, although DITA defines a methodology to manage this less
class CDATA "- grandfatherClass parentClass childClass ">
<xsl:template match="*[contains(@class,' childClass ']">
<!-- Matches any element that has a class attribute that mentions
childClass. This template takes precedence over one for
if the parentClass template is in an included style sheet. -->
However, I don't think existing XBRL taxonomies are defined with
something like the class attribute. Also, DITA is set up for DTD, and I
imagine it could be simplified a bit when using XML Schema.
*** Maybe certain XLink arcs provide the necessary information in the
existing XBRL schemas.
However, I haven't seen an XSLT example. I imagine it might be necessary
to "compile" the transitive series of one-level parent/child class role
information into a linearized "class inheritance list" attribute --
perhaps by making a separate pass with an XSLT spreadsheet to produce
the "compile time" relationships and which then drives the next step of
DITA-like XSLT processing.
[When I last looked at XSLT processors, they didn't seem to support XML
schema very well. Is this still true?]
*** As I posed the problem, I said that I wanted to have easily
maintainable general and specific XML schema files (two files) and
general and specific XSLT files (two more files) that are used directly.
Maybe it would be better to use XSLT and these four files to
automatically produce a problem-specific XSLT file (and perhaps a
problem-specific XML Schema) in which all the implicitly defined
combinations have been automatically generated.
This feels like a kluge to me, might produce very big files, and might
be difficult to use consistently and correctly. It's like using
different programs for the different passes of a compiler and leaving
the intermediate files laying around.
- Thanks in advance,
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list