[
Lists Home |
Date Index |
Thread Index
]
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/
|
