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

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:any />
     <xs:assert test="not(namespace-uri() = 'http://www.example.org')" />

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.

On Fri, Dec 17, 2010 at 4:22 AM, Ramkumar Menon
<ramkumar.menon@gmail.com> wrote:
> Gurus,
> I have a question.
> Are the following three definitions valid?
> 1.
> <any>
>   <assert test="not(namespace-uri() = 'http://www.example.org'"/>
> </any>
> 2.
> <anyAttribute>
>   <assert test="not(namespace-uri() = 'http://www.example.org'"/>
> </anyAttribute>
>  3.
> <any>
>   <assert test="not(node-name()= '{http://www.example.org}value-of)'"/>
> </any>
> If they are valid, can someone help explain why we need the notNamespace,
> notQName attributes explicitly?
> If the above definitions are *not* valid  - why?
> Ram
> --
> Shift to the left, shift to the right!
> Pop up, push down, byte, byte, byte!
> -Ramkumar Menon
>  A typical Macroprocessor

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