[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: inheritance and encapsulation in xslt? / xslt for

Subject: Re: inheritance and encapsulation in xslt? / xslt for xlink?
From: Howard Stearns <stearns@xxxxxxxxxxxx>
Date: Mon, 21 Jul 2003 17:36:53 -0400
xbrl xsd
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



Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

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

Buy Stylus Studio Now

Download The World's Best XML IDE!

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

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.