Re: [xsl] inheritance and encapsulation in xslt? / xslt for xlink?

[Howard Stearns <stearns@xxxxxxxxxxxx>]

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