Re: inheritance and encapsulation in xslt? / xslt for xlink?
2003-07-21 14:36:53
Thanks, Charles and David. I think you've got the idea, but I don't see
how include/import will handle it.
Let's say us-gaap-ci.xsd defines a large number of elements, and
us-gaap-ci-2html.xsl provides a transformation of a us-gapp-ci instance
document to XHTML for viewing.
<xsl:template match="UnrestrictedCash">cash is...
<xsl:template match="CashEquivalents">other liquid stuff is...
...
Now suppose that Acme Corp and World Financial Corp each produce
instance documents that use their own .xsd files, both based on
us-gaap-ci.xsd. Maybe us-gaap-ci-acme.xsd defines SlushFundCash as a
specialization of UnrestrictedCash, but both UnrestrictedCash and
CashEquivalents can appear directly in Acme instance documents.
I can't just use us-gaap-ci-2html.xsl to produce XHTML for these
company-specific instance documents, because many of the elements that
appear in the Acme instance documents are peculiar to the
us-gaap-ci-acme.xsd files. us-gaap-ci-2html.xsl can't define templates
that match the Acme names, because each company defines many of it's own
specific element names.
I could write an acme-corp-2html.xsl and a
world-financial-corp-2html.xsl and a zillion others, each including or
importing us-gaap-ci-2ht03.xsl. I don't mind defining templates for
those company-specific elements that I truly want handled in a
company-specific way. However, a large number of the company-specific
elements (oftentimes all of them) should just be handled in the same way
as the corresponding elements in the basic us-gaap-ci.xsd.
The various .xsd files conform to the XBRL standard, which specifies
that XLink arcs are used to indicate which company-specific elements
correspond to which elements in the basic us-gaap-ci.xsd. Specifically,
the standard says that an arc element appears in the company-specific
.xsd to connect the general element to the more specialized one, with an
XLink "arcrole" attribute of
"http://www.xbrl.org/2003/role#general-special". This specialization
process actually repeats many times. That is, the "general-special" role
is transative, and I want template behavior to default all the way up
the transitive chain of such roles.
In us-gaap-ci-acme.xsd:
<definitionArc
xlink:from="ci_unrestrictedCash"
xlink:to="acme_slushFundCash"
xlink:arcrole="http://www.xbrl.org/2003/role#general-special"/>
And indeed, in us-gaap-ci.xsd:
<definitionArc
xlink:from="ci_cashCashEquivalents"
xlink:to="ci_unrestrictedCash"
xlink:arcrole="http://www.xbrl.org/2003/role#general-special"/>
<definitionArc
xlink:from="ci_cashCashEquivalents"
xlink:to="ci_cashEquivalents"
xlink:arcrole="http://www.xbrl.org/2003/role#general-special"/>
<definitionArc
xlink:from="ci_totalCurrentAssets"
xlink:to="ci_cashCashEquivalents"
xlink:arcrole="http://www.xbrl.org/2003/role#general-special"/>
(And so on. Actually, I'm making a number of simplifications. In
particular, there's actually a child-parent role as well as
general-special, but I don't think that distinction is important here.)
So, one approach I thought of is to plan to always automatically
generate a default-acme-2html.xsl file based on the general
us-gaap-ci-2html.xsl, the us-gapp-ci-acme.xsd and the general-special
roles defined therein. This default .xsl file would define default
templates for each new Acme element which simply reproduced the template
behavior of the more general element for each newly defined specialized
element name. For example, it might automatically provide:
<xsl:template match="SlushFundCash">cash is...
<!-- based on UnrestrictedCash -->
If you want different behavior for some element, you could define a
non-default my-acme-2html.xsl that included the automatically generated
default-acme-2html.xsl.
(From this example, you might think that you would ALWAYS want to define
different output .xsl behavior for specialized elements, but I'm
asserting that this is not the case. In fact, for what I want to do
(conformance testing), it is NEVER the case.)
The idea of IBM's DITA is to give just enough information in the element
definitions (.dtd's, but it could work for .xsd's) that the
automatically generated default .xsl files are unnecessary. Instead of
defining templates on the names of elements, you define them on whether
the element has a defaulted class attribute (from the .dtd) that
includes the name of the element or one of its ancestors in the
general-special chain. For example, the us-gaap-ci-2html.xsl might
really define a template like:
<xsl:template match="*[contains(@class,' ci_unrestrictedCash ']">cash is...
Alas, XBRL does not appear to be set up to define this "class"
infrastructure. On the other hand, the DITA stuff predates .xsd and
XLink, so I'm hoping that there's now some standard way of dealing with
this problem that will work with XBRL .xsd's. My "QUICK SIMPLE QUESTION
(that could avoid all that follows, below)" was a guess (fantasy?) of
how that standard way might work.
So, is there a standard example or methodology for this?
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
|