On Thu, 2005-11-17 at 13:00 -0800, ext Orit Levin wrote:
> First, I would like to restate my support for the concensus below.
>  
> One of the major aspects to be addressed in the XCON data model is how
> to make it extensible by both standard and vendor specific content.
> 
> I started this discussion in
> http://www.ietf.org/internet-drafts/draft-levin-xcon-conference-package-
> ext-00.txt and presented the requirements in
> http://www.softarmor.com/xcon/meets/ietf64/slides/levin-conf-pkg-ext-iet
> f64.ppt. During the meeting Jari expressed his preference to just using
> RelaxNG for XCON instead, but this would require getting approval from
> the XML directorate and other interested parties. Jari also volunteered
> to talk to the "XML directorate" regarding this topic.
> 
> My preference would be to still take the precautions and RECOMMEND the
> simple conventions suggested in
> http://www.ietf.org/internet-drafts/draft-levin-xcon-conference-package-
> ext-00.txt in order to be compatible with the strict standard-compliant
> XML compilers and not just RelaxNG.
> 
> In any case, I suggest that we incorporate the alternatives into the
> common data draft and continue investigating both directions.
> 
> Thanks a lot,
> Orit.

E.g. in Simple WG W3C Schema has been used extensively. Also it has been
popular to add extensibility to the content models typically with 
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"
processContents="lax"/>
e.g.
...
<xs:element name="bar"/>
<xs:any namespace="##other" minOccurs="0" maxOccurs="unbounded"
processContents="lax"/>          
... 
Then you want to define an extension to the base spec, so that you'll
place an optional new element to that extension position, i.e. you'd
want to make a forwards and backwards compatible schema:
...
<xs:element name="bar"/>
<xs:element name="foo" type="ext_tns:foo" minOccurs="0">
<xs:any namespace="##other" maxOccurs="unbounded"
processContents="lax"/>          
... 
But you aren't allowed to do this as this violates the infamous Unique
Particle Attribution (UPA) constraint in Appendix H of the Schema spec.
There are several really ugly hacks to overcome this issue.

So the pragmatic model is just to define a new element with a new schema
and say "this element <xyx> extends the element <y> in the base spec.
Once you end up having many extension points the possible combinations
explode and w3c schema validation becomes more and more useless: it can
not detect wrongly positioned elements, root element can be any of the
global elements of the schemas, you can add undefined elements using the
namespaces of the extension schemas etc. Furthermore, UPA constraint
mandates to add new namespaces, I'd much prefer a situation where the
same namespace is re-used so that instance docs are much simpler to us
stupid implementers etc. Also the structures spec is so difficult to
understand that at least I'm unable to get almost anything out of it.

So why all this complaining ? There's a tool that doesn't have these
problems (RELAX NG). Besides, it is imo also much easier to understand
and use. Sure it ain't perfect either, but I'm frustrated because so
many are facing these same W3C Schema issues all the time. So my
preference is to use a tool that fits to the task at hand. 

Probably a comparison I-D of the features would help for WGs to decide
what tools should they use, but personally I don't have doubts what's
the best for pragmatic work (this includes even on-the-fly validations)

thanks,
Jari

_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon