OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] How to get XPath in a XSLT shylesheet

Michael Kay writes:

> Even given that requirement, it could have recognized that its quite
> possible to do validation without doing default value expansion: 

Well, I think Schema 1.1 is moving in that direction.  Default value 
expansion, as you know, really just adds properties to the Post Schema 
Validation Infoset.  In Schema 1.1, the PSVI is presented essentially as a 
taxonomy of information that processors MAY report.  Various conformance 
profiles are then offered to describe processors that offer particular 
useful combinations of such information in a compatible manner.  Although 
various communities are free to promote conformance levels for processors 
meeting particular needs (perhaps processors that provide just the 
information needed for building a high fidelity XQuery data model), the 
Schema 1.1 draft Recommendation proposes a few standard conformance 
levels.  Two of them seem to call for what you are requesting.  The 
so-called Instance-Validity Subset provides these properties only [1]:

[Definition:]   The instance-validity subset of the PSVI consists of the 
·root-validity subset·, plus the following properties on elements, 
wherever applicable:

    * [validity]
    * [validation attempted]
    * [notation system]
    * [notation public]
    * [schema error code]

and the following properties on attributes, wherever applicable:

    * [validity]
    * [validation attempted]
    * [schema error code]

The root validity subset provides an even smaller amount of information, 
and is intended for use in situations where it's known that the 
application really just wants a net report: the whole tree was OK, or it 
wasn't.   That is defined as [2]:

[Definition:]  The root-validity subset of the PSVI consists of the 
following properties of the ·validation root·:

    * [validity]
    * [validation attempted]
    * [schema error code], if applicable

Of course, it's up to you whether you support these subsets at all, and if 
so whether you do it by doing a fully general assessment and only 
reporting the requested subset, or whether you build a piece of code 
that's optimized to report only the subset that's needed.

For better or worse, I don't think the inverse is possible.  Because 
element declarations can be locally scoped, you typically can't assign 
defaults to elements and attributes without doing at least quite a bit of 
the work of validation.

BTW: I think if this discussion gets into much more detail, we should 
probably move it to schema-dev.


[1] http://www.w3.org/TR/xmlschema11-1/#dt-instance-validity_subset
[2] http://www.w3.org/TR/xmlschema11-1/#dt-root-validity_subset

Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS