RE: [xml-dev] xsd:anyType and xsd:any

[noah_mendelsohn@us.ibm.com]

You are most welcome.

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

"Shlomo Yona" <S.Yona@F5.com> 03/21/2007 12:55 AM

To:        <noah_mendelsohn@us.ibm.com>         cc:        <xml-dev@lists.xml.org>         Subject:        RE: [xml-dev] xsd:anyType and xsd:any

Thanks a lot.
It is clear now.
 
Shlomo.

---

From: noah_mendelsohn@us.ibm.com
[mailto:noah_mendelsohn@us.ibm.com] 
Sent: â 20 îøõ 2007 21:57
To: Shlomo Yona
Cc: xml-dev@lists.xml.org
Subject: RE: [xml-dev] xsd:anyType and xsd:any
 

Shlomo Yona writes: 

> OK. So, both xsd:any and xsd:anyType refer to a subtree. While the
> default parseContents for xsd:any is "strict" the parseContents
for 
> xsd:anyType is "skip"?

I'm afraid you are still confused.  As I said before, one of these
is a "type".  The architectural purpose of a type in XML
schema is to be a constraint on what you're calling a subtree, I.e. independent
of the name of an element, what are its legal contents.  

xsd:any is not a type, but it's usable as a term of a particle.  It
doesn't directly constrain a subtree at all.  Particles are things
like the references to elements A and C in the following.

        <xsd:complexType name="T">
       <xsd:sequence>
               <xsd:element ref="A"/>
               <xsd:any />
               <xsd:element ref="C"/>
       </xsd:sequence>
       </xsd:complexType>

You will note that these references are to the >name< of an element
(will, literally to the declaration).  The particles in the sequence,
in this example, tell what element >names< may appear as >immediate
children< of the element of type T.   They also do get you started
on validating those elements, because they get you to the element declarations,
which in turn have types, which in turn constrain the contents of those
elements, perhaps by having groups such as sequences, which have particles....and
the whole thing is thus recursive.  The <xsd:any> here is just
a special type of particle that matches any name.  >It is NOT a
type!< There are controls you can put on the xsd:any to make it match
only names in certain namespaces, etc., as I assume you've read in the
schema Recommendation [1]. 

There is no such thing as parseContents, but there is processContents on
the wildcards.  Since the wildcard can match elements of any name,
there's a possibility that some such elements will have (global) declarations
in the schema and some won't.  In case that's of concern to the schema
author, processContents merely tells whether it's an error not to have
such declaractions, whether they are to be ignored even if present, or
whether they are to be used if available to validate the content, but not
cause an error if missing. 

As I said in my first note, the built in type named xsd:anyType behaves
as if it had a wildcard in it for elements (and another for attributes,
by the way.)  anyType is magic in some ways, but it's a useful approximation
for some purposes to assume the wildcard is there.  As you will see
at [2], the Recommendation says:

"There is a complex type definition nearly equivalent to the ·ur-type
definition· present in every schema by definition. It has the following
properties:"  (in this, ur-type definition means xsd:anyType
-- don't ask!)  If you look at that, you will see that its particles
property is defined as: 

{particles}
a list containing one particle with the following properties:

Property

Value

{min occurs}

0

{max occurs}

unbounded

{term}

a wildcard with the following properties:

Property	Value
{namespace constraint}	any
{process contents}	lax

So, there's your answer:  it's lax.  (There is something funny
going on there, because this is the root of the type hierarchy, yet lax
will reject some things that skip will accept.  We had extensive discussions
for Schema 1.1 about doing something to fix that, but my somewhat vague
recollection is that we didn't come up with anything sufficiently satisfactory
to propose as a change.  So, that's a glitch if I'm remembering correctly.)

Noah 

[1] http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#Wildcards
[2] http://www.w3.org/TR/2004/PER-xmlschema-1-20040318/#d0e9210

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

"Shlomo Yona" <S.Yona@F5.com> 03/20/2007 12:29 PM

To:        <noah_mendelsohn@us.ibm.com>        cc:        <xml-dev@lists.xml.org>        Subject:        RE: [xml-dev] xsd:anyType and xsd:any

Hello, and thanks for your detailed answer.
Actually, reading the references that you listed got me into this confusion...

OK. So, both xsd:any and xsd:anyType refer to a subtree. While the default
parseContents for xsd:any is "strict" the parseContents for xsd:anyType
is "skip"?

How can I tell the default parseContents of such "joker" or "wildcard"
definitions?

Thanks.

Shlomo.




-----Original Message-----
From: noah_mendelsohn@us.ibm.com [mailto:noah_mendelsohn@us.ibm.com] 
Sent: â 20 îøõ 2007 17:36
To: Shlomo Yona
Cc: xml-dev@lists.xml.org
Subject: Re: [xml-dev] xsd:anyType and xsd:any

Shlomo Yona asks:

> I was not able to fully understand the difference between an xsd:any
> and an element with a type xsd:anyType.

Very different.  xsd:anyType is a type, like xsd:integer (though 
xsd:anyType is special in that it can act as a simple or complex type,
and 
it places essentially no restrictions on the tree that it validates --
thing of it loosely as the Schema language's analog of java.lang.Object).
A sample use would be:

       <xsd:element name="e" type="xsd:anyType"/>

This would mean that elements named <e> can have any content, any
attributes, etc.

xs:any is a wildcard, usable as a term in a content model.  For example:

       <xsd:complexType name="T">
       <xsd:sequence>
               <xsd:element ref="A"/>
           <xsd:any />
               <xsd:element ref="C"/>
       </xsd:sequence>
       </xsd:complexType>

Elements of type T must have content <A/><???/><C/>,
where <???> can be 
any named element.  Now, if you look really closely there is an 
approximation to the definition of xsd:anytType given for reference in
the 
Recommendation, and it uses an xsd:any wildcard as the means of saying
that it allows any elements. 

I hope you'll see that most of your questions are answered once you get
the above straight.  I would encourage you to carefully read the schema
primer [1], or some of the good books on W3C XML Schema (Priscilla 
Walmsley's is among the one's that's very well respected. [2]).

Noah

[1] http://www.w3.org/TR/xmlschema-0/
[2] 
http://www.amazon.com/Definitive-XML-Schema-Priscilla-Walmsley/dp/0130655678/ref=sr_1_1/103-2086530-8739813?ie=UTF8&s=books&qid=1174404823&sr=8-1

--------------------------------------
Noah Mendelsohn 
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------








"Shlomo Yona" <S.Yona@F5.com>
03/20/2007 11:08 AM

       To:     <xml-dev@lists.xml.org>
       cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
       Subject:        [xml-dev] xsd:anyType
and xsd:any


Hello,

I was not able to fully understand the difference between an xsd:any and
an element with a type xsd:anyType.

Is there any difference?
Do both wildcard methods refer to any child element(s) or does one or both
refer to a wildcard subtree?
What should be the parse mode (parserContents) for processing xsd:anyType?
Should is be same as xsd:any’s “skip” or “lax” or “strict” or perhaps
to 
something else?
The section 3.4.7 Built-in Complex Type Definition (in 
http://www.w3.org/TR/xmlschema-1/) says, if I understand correctly, that
the subtree should be processed in “lax”. Is that so?
What’s the difference, if any between the following wildcard definitions
(with regards to the depth of subtree they refer to, the processing mode
and any other issue):
·         xsd:any
·         element definition with type=”xsd:anyType”
·         a complexContent that has a restriction base=”xsd:anyType”
with 
an xsd:anyAttribute namespace=”##other” and processorContents=”lax”
·         a complexContent that has a restriction base=”xsd:anyType”
with 
an xsd:anyAttribute namespace=”##other” and processorContents=”skip”
Thanks.

Shlomo.