This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: XSLT/XPath 2.0 (was "Identifying two tags...")


Hi Bryan,

> I figure that there would be some basic rules for how validation
> would take place, that is to say a top-level element where you could
> declare how the validation would work, <xsl:validating/> this would
> take several attributes, one of which I suppose would be
> fail-on-error="yes|no" if fail-on-error equals yes, you fail on the
> first error and return the error message pertinent to your failure,
> if fail-on-error equals no then you do as a Sax parser or
> XmlValidatingReader, process the xml, report all errors, by report
> all errors I mean that errors should be available to your xslt as
> I'll talk about later. <xsl:validating fail-on-error="yes"/> in
> other words validates against your schema prior to processing, or at
> any rate could be implemented in such a way that it did so.

Right, so you want to be able to run validation from within the
stylesheet and, at user option, have the transformation fail if the
source document isn't valid.

I'd guess that this would be better as a task that should only be
carried out by XSLT processors when doing the whole
document-to-document transformation rather than when doing the
tree-to-tree transformation.

>>From there on in, yes I would like to get information about the
> validation at a low level, which I suppose comes out to being about the
> same as getting ahold of the overall valid/invalid result of that
> validation from within the stylesheet. Consider if I had a global
> parameter
> <xsl:param name="notValid">
> <xsl:apply-templates select="/" mode="validationCheck"/>
> </xsl:param>
>
> <xsl:template match="/" mode="validationCheck">
> <xsl:apply-templates select="*[valid() = 'NotValid']"
> mode="validationCheck"/>
> </xsl:template>
>
> I don't think there should be provided overall valid/invalid results, I
> think one should retrieve them oneself,

Right. I think that an element can't be valid if an element or
attribute it contains is invalid, so basically the validity of the
document as a whole is equivalent to the validity of the document
element. So it's not necessary to have a special way of retrieving the
validity of the document as whole.

> now let us suppose that you are rather concerned about some portion
> of your xml document
> <xsl:if test="valid() = 'NotValid'">
> <xsl:value-of select="validateError(.)"/>
> </xsl:if>
> or something like that, this would mean that you would retrieve the
> validateError provided by your schema implementation, in the case of
> Schematron it would be a message, in the case of some Xml Schema
> implementation it might be generally unhelpful text gobbledygook :)

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>

> finally a function that might be useful would be
> getValidator(Customer/CustID) which would return the information of
> your validation language regarding the particular Xpath fed in.
> Obviously this could lead to difficulties, i.e our validation
> language is Xml Schema and there's all sorts of confused datatyping
> going on here, but I thought specifically as Wendell noted earlier
> you can't do analysis of Xml Schema very easily from Xslt cause
> there's too many possible ways to handle it, very well, this should
> return a nodeset that you can do analysis of.
>
> This would mean that an Xslt 2.0 implementation allowing for using
> DTD as your validating language would be somewhat hampered (it would
> have to return things inside a CDATA section obviously)
>
> The benefit would be something like the following in Xslt 2.0
>
> <xsl:template match="Customers">
> <xsl:variable name="checkV" select="getValidator(Customer/@CustID)"/>
> <xsl:variable name="checkI">
> <xsl:choose>
> <xsl:when test="Customer/@CustID + 1 ='NaN'">
> Not a Number 
> </xsl:when>
> <xsl:when test=" Customer/@CustID = ' '">
> blank
> </xsl:when>
> </xsl:variable>
> <xsl:if test="valid() = 'NotValid'">
> <xsl:text>your entry for Customer ID was non-valid, according to our
> records you entered <xsl:value-of select="Customer/@CustID"/> a value
> that was <xsl:value-of select="$check1"/>
> please retry your entry again and enter a value of type <xsl:value-of
> select="$checkV/xsd:attribute/@type"/>
> </xsl:text>
>
> </xsl:if>
> <xsl:apply-templates/>
>
> </xsl:template>

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
definition/declaration.

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>

and:

  <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>

and:

  <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()]" />
</xsl:template>

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
information.

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.

Does anyone else have any comments about what's required from the
combination of schemas (of all flavours) and XSLT?

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]