[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
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
|