[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XPath/XSLT 2.0 concerns
Hi David, > Another idea about schema support: > ----------------------------------------------- > > If schema support must be added to XSLT I think it should be very > generic and non-intrusive. One idea I've been thinking about is to > use a schema axis together with a suitable abbreviation. What nodes > to expect on the schema axis should not be specified in the XSLT > specification, but in separate specifications for each schema > language. There could however be top level elements that provide a > standard way to assoicate a stylesheet with a schema. Something > along the following very hypothetical example: > > Schema fragment (in the RELAX NG compact syntax): > > value = element foo { xsd:int } | element bar { xsd:anyURI } > > Stylesheet fragment (assuming '#' for the abbreviation of 'schema::'): > > <xsl:load-schema href="myschema.rng" > type="http://relaxng.org/ns/structure/1.0"/> > <xsl:template match="schema::value"> > <xsl:text>Value: </xsl:text><xsl:apply-templates/> > <xsl:template> > <xsl:template match="#xsd:int"> > <xsl:text>Integer: </xsl:text><xsl:value-of select="."/> > </xsl:template> > <xsl:template match="#xsd:anyURI"> > <xsl:text>URI: </xsl:text><xsl:value-of select="."/> > </xsl:template> I think that this is a cool idea, and (aside from the schema-independence, which I understand is your point here) it's close to where XPath 2.0 is heading. I do worry a bit about moving such stylesheets between schema languages if what you find at the end of the schema:: axis could be different from schema language to schema language. What I've been dreaming about, for my fantasy XPath, is something where axes themselves are fairly modular from word go. (Basically they're just a shorthand for calling a function that accepts a node and returns a sequence of nodes, but to make it fit with node tests and predicates you need to also specify its principal node type and whether it's a forward or reverse axis.) Core XPath would define the abbreviated axes: child, parent, descendant-or-self. The XPath-for-XSLT module would add the other ones used by XSLT. And then other modules could specify whatever axes they wanted, in a namespace. So for example a W3C XML Schema module could declare the axis "xs:type" to get a node representing the type definition of the context node. A RELAX NG module could declare the axis "rng:annotation" to get nodes representing the annotations on the definition of the context node, if there are any. And so on, as appropriate for the schema language. The modules would also have to specify the node types that were relevant to the particular schema language, supplying a definition for the common node properties and accessor functions as defined in the Core XPath. But they could also define functions, or, of course, more axes, for getting information about the kinds of nodes that they defined, as long as they specified something like "for all other node types, this returns an empty sequence". I really ought to write this all up somewhere... Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|