RE: [xsl] XSLT/XPath 2.0 (was "Identifying two tags...")

Subject: RE: [xsl] XSLT/XPath 2.0 (was "Identifying two tags...")
From: "bryan" <bry@xxxxxxxxxx>
Date: Tue, 14 May 2002 18:28:46 +0200
>OK, so you'd like a way of seeing whether an individual node is valid
>or not, and a way of retrieving the message associated with the
>validity error if there is one.

>One way of supporting that would be to add a 'validity error' property
>to the XPath 2.0 data model, holding an error object for invalid
>nodes, and an empty sequence otherwise. And then have something like:

>  <xsl:if test="validity-error()">
>    <xsl:value-of select="get-message(validity-error())" />
>  </xsl:if>

fine, one of the things that I think we should want is a little more
control over our error responses, just like any other programming
language offers, or at least most that I've seen. This allows us to
build apps where xslt functions as the error handler, and the validation
language functions as the error generator.

>Very interesting. You want to have some way of retrieving a node (or
>maybe sequence of nodes) that represent the constraint against which
>the particular node (from the source document) was validated. For
>XML-based schemas, this could be an element (a xs:element element if
>you validated against XML Schema, a sch:pattern element if you
>validated against Schematron, a rng:element element if you validated
>against RELAX NG). For DTDs, or schemas in non-XML syntax (such as the
>RELAX NG non-XML syntax), you want a text node holding the appropriate

Also it does put some weight on the benefit of using XML syntax schema
languages, which I think W3 should be more concerned with than with Xml
Schema syntax specifically. Because with an XML Syntax you will get a
node/sequence of nodes back. 

>Then you want to manipulate that node as you can any other.


>That would certainly be very flexible. I personally like the idea
>because it would mean that people were able to do some tasks that they
>can't under the current model, and that I think could be quite useful:

>  - test whether this attribute has a value that's the same as the
>    default value for the attribute
>  - retrieve the list of values that are allowed for this element
>  - get hold of the documentation/appinfo that's associated with this
>    element in order to retrieve a label of some sort

>I've seen people request the first two, usually when they're creating
>a form based on a schema and a given instance -- they want to take:

>  <flavour>chocolate</flavour>
>  <xs:element name="flavour" default="vanilla">
>    <xs:simpleType>
>      <xs:restriction base="xs:token">
>        <xs:enumeration value="vanilla" />
>        <xs:enumeration value="chocolate" />
>        <xs:enumeration value="mint" />
>        <xs:enumeration value="coffee" />
>      </xs:restriction>
>    </xs:simpleType>
>  </xs:element>
>and generate:
>  <select name="flavour">
>    <option>vanilla</option>
>    <option selected>chocolate</option>
>    <option>mint</option>
>    <option>coffee</option>
>  </select>

>I think that getting hold of the documentation associated with a node
>could be handy too, because it would mean there was a sensible place
>to put all the data elements that we find we have to create. For
>example, if you had:
>  <flavour>CHC</flavour>
>  <xs:element name="flavour" default="VNL">
>    <xs:simpleType>
>      <xs:annotation>
>        <xs:appinfo>
>          <flavour code="VNL">Vanilla</flavour>
>          <flavour code="CHC">Chocolate</flavour>
>          <flavour code="MNT">Mint</flavour>
>          <flavour code="CFE">Coffee</flavour>
>        </xs:appinfo>
>      </xs:annotation>
>      <xs:restriction base="xs:token">
>        <xs:enumeration value="VNL" />
>        <xs:enumeration value="CHC" />
>        <xs:enumeration value="MNT" />
>        <xs:enumeration value="CFE" />
>      </xs:restriction>
>    </xs:simpleType>
>  </xs:element>
>then you could create:
>  Your favourite ice cream is Chocolate
>with something like:
><xsl:template match="flavour">
>  <xsl:text>Your favourite ice cream is </xsl:text>
>  <xsl:value-of select="schema(.)//flavour[@code = current()]" />

in a way takes some of the work off of document() and puts it on your
schema implementation, with probably less resource expenditure. It also
means appinfo would become very useful.

>The advantage of keeping this information in the schema is that
>multiple stylesheets, and indeed other tools, can take advantage of it
>-- it gives a single central location in which to maintain the

>On the other hand, it would mean that the processor would have to keep
>around another node tree in addition to the source node tree, and the
>stylesheet author you would still have to have pretty good knowledge
>of how the schema was organised in order to take advantage of the
>information that it contains, though admittedly not nearly as much as
>if all you had to work out which element declaration you should be
>looking at yourself.

I'm betting there could be a lot of optimization of that additional node
Also just as there is today with xslt 1.0 a lot of importable includable
stylesheets are written by the people we would consider the frontrunners
of the community the same thing would happen with xslt 2.0, I think the
kind of stuff outlined above would allow more powerful generic
stylesheets / stylesheet libraries than the whole tight integration with
one particular schema language. 
Note that just as I am against tight integration with Xml Schema, I
would be just as opposed to any other tight integration with any
validation language.

 XSL-List info and archive:

Current Thread