Subject: RE: [XCON] WG Issues with XML Schema

From: "Brian Rosen" <[email-masked]>
Date: Wed, 4 Apr 2007 11:07:03 -0400

To me, this is the one that matters.

In the IETF, we're always extending things.  The contortions needed to
extend an XSD and keep it valid are complex.

Brian

> -----Original Message-----
> From: Oscar Novo (JO/LMF) [mailto:[email-masked]]
> Sent: Thursday, March 22, 2007 10:30 AM
> To: Pete Cordell; [email-masked]
> Subject: RE: [XCON] WG Issues with XML Schema
> 
> Actually, one of the problems we had was with the extensibility of the
> schema. Here you have an email from Jari Urpalainen explaining the
> issue:
> 
> http://www1.ietf.org/mail-archive/web/xcon/current/msg01527.html
> 
> Other important problems of XML Schema are number 7 (very critical
> one!), 2 and 6.
> 
> Hope this information will help you!
> 
> Oscar
> 
> 
> -----Original Message-----
> From: Pete Cordell [mailto:[email-masked]]
> Sent: 22. maaliskuuta 2007 15:50
> To: Oscar Novo (JO/LMF); [email-masked]
> Subject: Re: [XCON] WG Issues with XML Schema
> 
> Many thanks for this Oscar.  If I try and summarise each of James'
> points, I'd be interested know which are, say, the top 4 that you (or
> any one else on the list) were most affected by that led you to move
> away from XSD (I hope the focussed input can be of use to the schema
> working group):
> 
> 1. XSD requires significant expertise with things like the merging of
> wildcards in attribute groups being counter-intuitive.
> 
> 2. The XSD spec is hard to understand and not amenable to being easily
> referred to.
> 
> 3. XSD does not have a formal theoretical basis behind it (whereas RNG
> does).
> 
> 4. XSD does not have co-constraints, e.g. you can't make element X and
> attribute Y mutually exclusive.
> 
> 5. The xs:all (analogous to rng's interleave) feature is too weak.
> 
> 6. XSD's datatypes are not flexible/open enough (and yet saddled with
> things like gMonthDay).
> 
> 7. An XSD schema can validate seemingly bogus things such as <bogus/>
> when the schema never actually mentions a bogus element (I hope he's
> wrong about this!).
> 
> 8. Implicitly defined attributes such as xsi:schemaLocation and xsi:type
> conflict with your ability to define the grammer you want.
> 
> 9. Allowing the specification of default and fixed values is
> problematic.
> 
> And if I can add a few of my own issues:
> 
> 10. The rules for wildcards (xs:any) conflicting with element names can
> make versioning of a schema from V1 to V2 problematic.
> 
> 11. Enumerations are not readily extensible.
> 
> 12. There's no modularity in the schema definitions such that schema B
> can precisely add extensions to a core schema A.
> 
> Many, many thanks,
> 
> Pete.
> --
> =============================================
> Pete Cordell
> Tech-Know-Ware Ltd
> for XML to C++ data binding visit
> http://www.tech-know-ware.com/lmx/
> http://www.codalogic.com/lmx/
> =============================================
> 
> ----- Original Message -----
> From: "Oscar Novo (JO/LMF)" <[email-masked]>
> To: "Pete Cordell" <[email-masked]>; <[email-masked]>
> Sent: Thursday, March 22, 2007 12:03 PM
> Subject: RE: [XCON] WG Issues with XML Schema
> 
> 
> Hi Pete,
> 
> I suggest you to read the following e-mail from James Clark:
> 
> http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html
> 
> He's the designer of TREX. RELAX NG is based on TREX and RELAX.
> I think in this e-mail he explains very well the motivations inside the
> IETF to move towards RELAX NG.
> 
> Cheers,
> 
> Oscar
> 
> -----Original Message-----
> From: Pete Cordell [mailto:[email-masked]]
> Sent: 20. maaliskuuta 2007 19:01
> To: [email-masked]
> Subject: [XCON] WG Issues with XML Schema
> 
> I hope this isn't a mis-use of this list, but.....
> 
> As you may know, W3C XML Schema is in the process of being extended to
> version 1.1.  I know that XCON started out using XML Schema, but has
> since moved more towards Relax-NG.
> 
> I'm hoping that those making that change of direction will share with me
> their motivation for making that decision.  My intention would be, if
> appropriate, to share any gathered opinions with the XSD 1.1 working
> group (probably in some summarized form).  (BTW - Just to be clear, I'm
> not on the
> WG.)
> 
> For example, is XML schema just too difficult to learn?  Is the
> versioning and extensibility of elements, attributes and enumerations
> too restricted?
> Were there constraints on your syntax that you couldn't (readily)
> express using schema?  What else?
> 
> My motivation for doing this is that I feel that the usage scenarios for
> XCON, SIP and other similar IETF style protocols are very different from
> the sorts of use-cases that the majority of the W3C members are familiar
> with, and hence the requirements are under represented.  There's a
> chance that by giving me feedback, XSD 1.1 will do a better job of
> meeting the needs of working groups in the IETF.
> 
> I'm interested to hearing from anybody involved in schema work, whether
> it be in XCON, SIP, SIPPING, AVT, some other IETF group, or for private
> purposes.  However, I'm only posting this message to the XCON list in
> the hope this will capture most of the feedback (the membership of the
> previously mentioned groups is probably much the same anyway).
> 
> Depending on what you think is appropriate, you can either reply to the
> list, or direct to me.
> 
> Many, many thanks for you help in trying to make XSD 1.1. better!
> 
> Pete.
> --
> =============================================
> Pete Cordell
> Tech-Know-Ware Ltd
> for XML to C++ data binding visit
> http://www.tech-know-ware.com/lmx/
> http://www.codalogic.com/lmx/
> =============================================
> 
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon
> 
> 
> 
> _______________________________________________
> XCON mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/xcon

_______________________________________________
XCON mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/xcon

---

From: "Pete Cordell" <[email-masked]>
Date: Tue, 10 Apr 2007 11:55:45 +0100

Hi Brian,

Thanks for your reply  (I didn't reply earlier in case it solicited some 
further discussion.)

This is an area being looked at in XSD 1.1.  With the current drafted text, 
it would be possible to specify something like:

    <xs:element name='foo' minOccurs='0' type='xs:int'/>
    <xs:any namespace='##any' minOccurs='0' max.../>

With existing XSD 1.0 rules the wildcard would conflict with the 'foo' 
element.  The current XSD 1.1 text says that if a wildcard conflicts with an 
element declaration, then the element declaration wins.  Hence the above is 
OK.

One slight oddity is that the following instance would be valid:

    <foo>123</foo>
    <foo>456</foo>

Here, the first instance of <foo> matches the element declaration, and the 
second instance matches the wildcard.  Personally I don't think this is the 
right way to do things, and am trying to convince them of that.

There's also an example (based on peoples' names) where you couldn't go from 
(in v1):

      <xs:element name="given" type="xs:string"/>
      <xs:any namespace="##any" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="family" type="xs:string"/>

to:

      <xs:element name="given" type="xs:string"/>
      <xs:any namespace="##any" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="middle" type="xs:string" minOccurs="0"/>
      <xs:any namespace="##any" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="family" type="xs:string"/>

in a subsequent version (i.e. add a declaration for a <middle> name element, 
and another wildcard), because the two wildcards would conflict.  Instead 
you would have to do:

      <xs:element name="given" type="xs:string"/>
      <xs:any namespace="##any" processContents="lax"
         From [email-masked] Tue Apr 10 07:30:39 2007
From: "Pete Cordell" <[email-masked]>
To: "Brian Rosen" <[email-masked]>,
	"'Oscar Novo (JO/LMF)'" <[email-masked]>, <[email-masked]>
Subject: Re: [XCON] WG Issues with XML Schema
Date: Tue, 10 Apr 2007 11:55:45 +0100
Cc: 

Hi Brian,

Thanks for your reply  (I didn't reply earlier in case it solicited some 
further discussion.)

This is an area being looked at in XSD 1.1.  With the current drafted text, 
it would be possible to specify something like:

    <xs:element name='foo' minOccurs='0' type='xs:int'/>
    <xs:any namespace='##any' minOccurs='0' max.../>

With existing XSD 1.0 rules the wildcard would conflict with the 'foo' 
element.  The current XSD 1.1 text says that if a wildcard conflicts with an 
element declaration, then the element declaration wins.  Hence the above is 
OK.

One slight oddity is that the following instance would be valid:

    <foo>123</foo>
    <foo>456</foo>

Here, the first instance of <foo> matches the element declaration, and the 
second instance matches the wildcard.  Personally I don't think this is the 
right way to do things, and am trying to convince them of that.

There's also an example (based on peoples' names) where you couldn't go from 
(in v1):

      <xs:element name="given" type="xs:string"/>
      <xs:any namespace="##any" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="family" type="xs:string"/>

to:

      <xs:element name="given" type="xs:string"/>
      <xs:any namespace="##any" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="middle" type="xs:string" minOccurs="0"/>
      <xs:any namespace="##any" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
      <xs:element name="family" type="xs:string"/>

in a subsequent version (i.e. add a declaration for a <middle> name element, 
and another wildcard), because the two wildcards would conflict.  Instead 
you would have to do:

      <xs:element name="given" type="xs:string"/>
      <xs:any namespace="##any" processContents="lax"
              minOccurs="0" maxOccurs="unbounded"/>
      <xs:sequence minOccurs="0">
          <xs:element name="middle" type="xs:string" />
          <xs:any namespace="##any" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:element name="family" type="xs:string"/>

(i.e. add an optional sequence in which the <middle> name became mandatory, 
hence separating the wildcards.)  This seems messy to me, and I'd like to 
encourage them to permit the middle option (first extended example).

There's more examples at:

    http://www.w3.org/TR/xmlschema-guide2versioning/

So in summary, there is movement here.  But I think the usage scenarios that 
the IETF has for schema is under represented in the schema working group 
(for example, I suggested an xs:anyEnumeration facet to make extensible 
enumerations, rather than having to use the <union> trick, but got no 
takers.).

Therefore, I think it would be well worth some members of the IETF looking 
at what the W3C is doing and possibly sending them a liaison statement 
outlining the sorts of features they would find helpful in a new version of 
XML schema.  I believe there is an XML users group in the IETF.  Maybe this 
is something they could do.

Thanks again for your comments,

Pete.

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Oscar Novo (JO/LMF)'" <[email-masked]>; "'Pete Cordell'" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, April 04, 2007 4:07 PM
Subject: RE: [XCON] WG Issues with XML Schema

>>      minOccurs="0" maxOccurs="unbounded"/>
      <xs:sequence minOccurs="0">
          <xs:element name="middle" type="xs:string" />
          <xs:any namespace="##any" processContents="lax"
                minOccurs="0" maxOccurs="unbounded"/>
      </xs:sequence>
      <xs:element name="family" type="xs:string"/>

(i.e. add an optional sequence in which the <middle> name became mandatory, 
hence separating the wildcards.)  This seems messy to me, and I'd like to 
encourage them to permit the middle option (first extended example).

There's more examples at:

    http://www.w3.org/TR/xmlschema-guide2versioning/

So in summary, there is movement here.  But I think the usage scenarios that 
the IETF has for schema is under represented in the schema working group 
(for example, I suggested an xs:anyEnumeration facet to make extensible 
enumerations, rather than having to use the <union> trick, but got no 
takers.).

Therefore, I think it would be well worth some members of the IETF looking 
at what the W3C is doing and possibly sending them a liaison statement 
outlining the sorts of features they would find helpful in a new version of 
XML schema.  I believe there is an XML users group in the IETF.  Maybe this 
is something they could do.

Thanks again for your comments,

Pete.

----- Original Message ----- 
From: "Brian Rosen" <[email-masked]>
To: "'Oscar Novo (JO/LMF)'" <[email-masked]>; "'Pete Cordell'" 
<[email-masked]>; <[email-masked]>
Sent: Wednesday, April 04, 2007 4:07 PM
Subject: RE: [XCON] WG Issues with XML Schema