W3C has published eight new standards in the XML Family to support the ability to query, transform, and access XML data and documents. The primary specifications are XQuery 1.0: An XML Query Language, XSL Transformations (XSLT) 2.0, and XML Path Language (XPath) 2.0; see the full list below. These new Web Standards will play a significant role in enterprise computing by connecting databases with the Web. XQuery allows data mining of everything from memos and Web service messages to multi-terabyte relational databases. XSLT 2.0 adds significant new functionality to the already widely deployed XSLT 1.0, which enables the transformation and styled presentation of XML documents. Both specifications rely on XPath 2.0, also significantly enriched from its previous version. W3C‘s XSL Working Group and XML Query Working Group, who created these specifications, have addressed thousands of comments from implementers and the interested public to ensure that the specifications meet the needs of diverse communities. The eight Recommendations published today that together increase the power of the XML family are: 1. XML Path Language (XPath) 2.0, 2. XSL Transformations (XSLT) Version 2.0, 3. XQuery 1.0: An XML Query Language, 4. XML Syntax for XQuery 1.0 (XQueryX), 5. XQuery 1.0 and XPath 2.0 Data Model (XDM), 6. XQuery 1.0 and XPath 2.0 Functions and Operators, 7. XQuery 1.0 and XPath 2.0 Formal Semantics, and,8. XSLT 2.0 and XQuery 1.0 Serialization. http://www.w3.org/
XBRL is, in some ways, a funny kind of XML language. It doesn’t make much use
of the capabilities within XML Schema to express relationships such as
order, hierarchy, and so on. Viewed strictly as XML, XBRL looks pretty flat,
without a lot of contextual constraints.
But that’s nonsense, of course. Financial documents are highly constrained
and contain intricate interrelationships. XBRL expresses these relationships
within "taxonomies"–special XBRL constructs that define business
"concepts" and that relate these concepts to each other. The
relationships can, in fact, be really complex …more so than would be possible
within a strict XML Schema definition.
Once consequence of this decision to define the bulk of XBRL semantics
outside the range of standard XML semantics is that XSLT (XML Stylesheet
Language Translator) doesn’t work very well
as a way to transform XBRL documents into something that humans can read. Since
"understand" the information in the XBRL taxonomy, XSLT does not have
the information that it needs to present the "facts" in an XBRL instance
in a way that reflects the taxonomy relationships.
So, how do people produce formatted output from XBRL today? In a Wednesday morning session at the 11th
International XBRL Conference, Raymond Lam of BlastRadius
explained that the usual solution is to hard-wire all
the necessary contextual information into the XSLT rules. The result is an XSLT
stylesheet that contains nearly as many separate template rules as there are
separate facts to be presented. Bummer.