Recipe 1.10. Exploiting XPath 2.0's Extended Type SystemProblemYou use XML Schema religiously when processing XML and would like to reap its rewards. SolutionIf you validate your documents against a schema, the resulting nodes become annotated with type information. You can then test for these types in XPath 2.0 (and while matching templates in XSLT 2.0). (: Test if all invoiceDate elements have been validated as dates. :) if (order/invoiceDate instance of element(*, xs:date)) then "invoicing complete" else " invoicing incomplete"
However, the benefit of validation is not simply the ability to test types using instance of but rather from the safety and convenience of knowing that there will be no type error surprises once validation is passed. This can lead to more concise stylesheets. (: Without validation, you should code like this. :) for $order in Order return xs:date($order/invoiceDate) - xs:date($order/createDate) (: If you know all date elements have been validated, you can dispense with the xs:date constructor. for $order in Order return $order/invoiceDate - $order/createDate DiscussionMy personal preference is to use XML Schemas as specification documents and not validation tools. Therefore, I tend to write XSLT transformations in ways that are resilient to type errors and use explicit conversions where needed. Stylesheets written in this manner will work in the presence of validation or not. Once you begin to write stylesheets that depend on validation, you are locked into implementations that perform validation. On the other hand, if your company standards say all XML documents will be schema-validated before processing, then you can simplify your XSLT based on assurances that certain data types will appear in certain situations. |