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

RE: XSLT and XML Schema

Subject: RE: XSLT and XML Schema
From: "Michael Kay" <mike@xxxxxxxxxxxx>
Date: Thu, 14 Jun 2007 09:19:09 +0100
RE:  XSLT and XML Schema
> Can you further elaborate on the changes to Saxon you mentioned above?

The XML Schema specs define an abstract data structure for "schema
components" such as element declarations, type definitions, and so on. At
this level, many of the differences between different ways of writing a
schema disappear, for example there's very little difference between a
global element declaration and a local element declaration. Saxon of course
builds the schema component model internally as a result of analyzing source
schema documents, and makes it available via a Java API. The new facility
will allow this model to be serialized as XML. 

To take an example of an element that happens to be empty with three
attributes, the element declaration CATEGORY might appear as:

   <scm:element id="C13" name="CATEGORY" type="C14" global="true"
nillable="false"
                abstract="false"/>
and its type as:

   <scm:complexType id="C14" base="#anyType" derivationMethod="restriction"
abstract="false"
                    variety="empty">
      <scm:attributeUse required="true" ref="C35"/>
      <scm:attributeUse required="true" ref="C36"/>
      <scm:attributeUse required="false" ref="C37"/>
   </scm:complexType>

and an attributeUse in turn points to an attribute declaration such as:

   <scm:attribute id="C35" name="CODE" type="#ID" global="false"
containingComplexType="C14"/>

(#ID is a reference to a built-in type as distinct from a type defined
elsewhere in the SCM document)

So: you don't have to follow include/import links; the way an element refers
to its type is the same whether the type is named or anonymous; defaulted
values are explicit; you don't have to follow references to named model
groups or named attribute groups; all the elements are on the same level,
distinguished by the attribute global=true|false. Moreover, the semantics of
the model are very closely aligned with the XML schema specifications which
means there's some fairly rigorous documentation of what everything means.

The initial objective for this was to make it faster to load a schema that
has already been validated; the fact that the information is more accessible
to applications is a useful spin-off.

Going back to the original post, if you want to know the set of attribute
names allowed on the CATEGORY element, then in a schema-aware query it's 

let $e := /*/scm:element[@global=true() and @name=QName('', 'CATEGORY)]
let $t := /*/scm:complexType[@id=$e/@type]
let $au := $t/scm:attributeUse
let $a := /*/scm:attribute[@id=$au/@ref]
return $a/@name

(Actually, I think that if the type is derived by extension you do need to
follow the link to the base type as well, so it's a little bit more
complicated than that; but it should be possible to define a useful set of
functions that take care of such things.)

Michael Kay
http://www.saxonica.com/

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.