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 15:58:07 +0200
>When you say that you want support for RELAX NG and Schematron as
>schema languages, what differences do you want validation against
>those schema languages to make to XSLT processing? Do you simply want
>your XSLT processor to validate against one of these prior to
>processing? Do you want to get hold of the overall valid/invalid
>result of that validation from within the stylesheet? Do you want that
>record of the validation to be available at a low level (i.e. flags on
>individual elements to say whether they're valid or not; Schematron
>messages to indicate what the error is)? Do you want other information
>that arises from validation, such as the name of the <def> that
>defines the content of an element, or the type of the data in an
>attribute, to be available?

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. 
>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, 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 :)
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>
anyhow this is not any walk in the park obviously, and I had to cut
corners on this example cause I'm stuck for time and have to do some
demos later on this afternoon.


>XML Schema can't even validate itself :) That said, it's really quite
>difficult to articulate every constraint on a particular markup
>language, even with the best schema languages.

Agreed, but it becomes ever more difficult the more you move your
validation language away from just validation. 
The different languages do different things, I happen to appreciate
Schematron cause it's very easy to conditional, partial document
validation, just focusing on those parts you consider likely to be
trouble areas. 
Anyhow, I know the above is not that great, and there are far better
people on this list to work these kinds of things out, but I think
something like this, difficult though it might be, would probably be
preferable, and then leave the tighter integration to vendor specific
extensions, which will come(Microsoft already has quite a few xpath
extensions for working with Xml Schema in msxml 4)



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


Current Thread