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] Help - any/anyAttribute - notNamespace, notQName

Other than the points I shared below, I think using assertions to meet
the validation objectives that can be accomplished by notNamespace
and/or notQName for example, is not good in a sense that assertion
evaluations require an XDM tree in memory (building this tree is an
overhead for the XML schema validator -- both processing and memory

Therefore my recommendation is not to use XML schema assertions, if
the XML instance objectives can be achieved by notNamespace and/or

On Fri, Dec 17, 2010 at 1:37 PM, Mukul Gandhi <gandhi.mukul@gmail.com> wrote:
> Hi Ram,
>    It seems you're referring to XML Schema 1.1 assertions. The
> definitions cited in your examples are *not* syntactically correct
> (xs:assert could not be a child of xs:any).
> XML Schema assertions are defined at a level of complexTypes (and also
> as facets on simpleType's). For e.g something like:
> <xs:complexType name="MYTYPE">
>     <xs:sequence>
>         <xs:any />
>     </xs:sequence>
>     <xs:assert test="not(namespace-uri() = 'http://www.example.org')" />
> </xs:complexType>
> But here are the issues I see with using assertions on xs:any wild-card:
> 1. For xs:any (i.e with the wild-card "strict" mode) the element
> instance will be validated by the element particle in scope of the
> validation episode. Therefore any constraint on the wild-card via
> assertions (for e.g a namespace constraint that you've specified) may
> conflict with the targetNamespace of the element particle. Since
> affect of assertions is a boolean and to the element particle
> constraint in this case, I think using assertions for wild-card strict
> mode is a poor XML schema design.
> 2. For xs:any with "lax" mode, I see assertions to have few valid uses
> but only if there is no element particle available to validate the
> corresponding element instance. Again if an element particle is
> available in scope to validate the XML information item, then effect
> of assertions is a boolean and to the element particle constraint,
> which to my opinion is not a good design.
> 3. For xs:any with "skip" mode, I do not see any good uses of XML
> schema assertions. In case of Xerces for xs:any wild-card "skip" mode,
> the corresponding element information items are not available in the
> XDM tree on which assertions operate, therefore assertions are not
> much useful for wild-card "skip" mode.
> To my opinion, using the XML schema component attribute instructions
> notNamespace and notQName is a better idea to have constraints on
> namespace and Qname's of information items (the elements and
> attributes) instead of using schema assertions.
> I think assertions would be more useful when bound to wild-card
> instructions, for e.g to place constraints on aspects of child tree
> (like how many children, white space constraints etc) of the root
> element information item.

Mukul Gandhi

[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