Perhaps a qualification of "validity" might help to clarify the
intent. For XML documents, there is a lexical level and, roughly
following the separation outlined by the XML Schema documentation,
there is "structure" and "data type".
I concentrate on the validity of data, according to simple data types.
Let's assume that there is a way to validate against an XML schema
where all simple types have been replaced on the fly by xs:string. I
suppose that, based on a valid structure, you could access all kinds
of nodes and validate their string data against the true data type in
the pertaining XML schema. Perhaps this can be achieved with today's
features in XSLT x.y - I'm not an expert.
-W
On 24/07/2013, Michael Kay <mike(_at_)saxonica(_dot_)com> wrote:
I think you're mixing a statement of requirements with the proposed design
of a solution. It would be useful to keep the two separate. I've no problem
with your requirements (I think), but would design the solution
differently.
On 24 Jul 2013, at 10:36, Costello, Roger L. wrote:
Hi Folks,
I have a use case that I think is important and will benefit many people.
I would like for the XSLT 3.0 working group to support this use case.
Below is an initial set of requirements needed for this use case.
REQUIREMENT #1
<xsl:copy validation="lax"> shall not fail validation (i.e., the context
item is annotated valid) if the context item is valid without
consideration of its child elements.
What you're really asking for here is validation="local"; i.e. testing
whether the element is locally valid against a type, in the terminology of
XSD.
I think the main problem with this is that implementing this would require
fine-grained interaction between the XSLT processor and the schema
processor. There are XSLT implementations that use third-party schema
processors (e.g. XMLPrime uses the Microsoft .NET schema processor) and we
would be reluctant to do anything that made such a design impossible.
REQUIREMENT #2
When control falls into xsl:catch, the context item is exactly the same as
the context item of the xsl:try.
I think that's already one of the rules of try/catch.
In fact, the context item is exactly as it was before the xsl:try -- it is
as though the xsl:try never happened. The xsl:try must not alter the
context item in any way if validation fails.
REQUIREMENT #3
<xsl:copy validation="lax"> shall fail validation (i.e., the context item
is annotated invalid) if the context item is invalid and/or its text is
invalid.
We don't currently have any concept of annotating something as invalid.
I think what you are really looking for -- or at any rate, the way a W3C WG
would address you requirement -- is for XSLT to have more complete support
of the PSVI. I think you want a mode of validation in which invalidity is
not an error, but results in information about the nature and location of
the invalidity being made available to the application. That information is
essentially the PSVI, or some useful subset thereof.
There are some significant challenges in achieving this. One point to note
is that it's incompatible with streaming (the type of a node is known when
you see its start tag, but its validity against that type is only known when
you see the end tag).
In practical engineering terms, I think implementors might still have some
difficulty achieving this with third-party schema processors, because schema
processors don't all offer full access to the PSVI. But at least it would
only rely on features that conformant schema processors are supposed to
provide.
I don't think I would tackle this requirement with a design based on
try/catch, I would tackle it with an approach in which invalidity is not a
dynamic error.
Michael Kay
Saxonica
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--