OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Re: Language Theorie concerning XML Schema (heavy,atleast

[ Lists Home | Date Index | Thread Index ]
  • To: xml-dev@lists.xml.org
  • Subject: Re: [xml-dev] Re: Language Theorie concerning XML Schema (heavy,atleast to me)
  • From: Rick Jelliffe <ricko@allette.com.au>
  • Date: Mon, 02 May 2005 20:28:20 +1000
  • In-reply-to: <28237ff2a93b89f1ad69a26f3c20451c@whatfettle.com>
  • References: <BBF4F4DF-0DDA-4E82-8F7C-8F80EA8E3856@host1web.com> <1114548194.9178.165.camel@localhost.localdomain> <426F1628.6030201@mihaiu.name> <642f07b6050427215328609939@mail.gmail.com> <427070FB.8030806@allette.com.au> <642f07b60504280007377ba5ac@mail.gmail.com> <642f07b60504280307755d53e@mail.gmail.com> <f5bd5sf6vm5.fsf@erasmus.inf.ed.ac.uk> <4270FECE.7050709@objfac.com> <f5br7gu3m9w.fsf_-_@erasmus.inf.ed.ac.uk> <4271BDB4.80706@objfac.com> <4271DCF8.7010202@allette.com.au> <28237ff2a93b89f1ad69a26f3c20451c@whatfettle.com>
  • User-agent: Mozilla Thunderbird 0.6 (X11/20040502)

Paul Downey wrote:

> I think there already is an implicit databinder's profile out there, 
> in the
> form of whatever nugget of schema is widely implemented consistently by
> vendors. Trouble is that it isn't clear to the average publisher of
> a schema which bits are core and which are esoteric.

I expect there will be more information on the net if user get 
frustrated and start
to blame the vendors.

> I'm, personally, fairly open to a profile, but maybe improved test cases
> or clarifications of the spec itself could be sufficient. I don't know.

I think there is a basic operational problem in XML Schemas: it is designed
with a kind of "dynamic discovery" model. So when you find the root
element, you start looking for the schema that matches that namespace,
if there is @xsi:type you don't look at the element name you look at the
type name, and you look up the type names when you need them and
don't signal an error if they are found and not needed, and type attribution
is performed in the context of the current namespace-branch: top-down.

This notional processing model is very consistent, but schema-compiling
or schema-using toolkits prefer/require that the schema is known, fixed, 
(i.e. no wildcards)  and complete.

Now I am not saying that a tricky schema-compiler could not have
tricks to cope: for example, generating extra tables to handle wildcards
or more complex dispatching rules that cope with @xsi:type.  But it seems
to me that the dynamic discovery model for XML Schemas may be the
nub of the problems.  Are implementers voting with their code, that it 
worth their time to implement parts that they don't want their users to use?

> However in my day job i'm getting fairly frustrated as more or less
> each and every new schema i'm faced with seems to lead to yet another
> learning experience followed my having to deliver bad news to customers
> /i'm afraid your schema is being rejected by toolkit *bah*, maybe you 
> might
> like to simplify it if you want to reach a wide market? 

Care to name the particular issues?  Non-specific comments won't have much
traction with vendors or standards-makers.

The XQuery folk should be very concerned too: if XML Schemas gets
a name for being a sure way to guarantee non-interoperability in 
XML Systems, XQuery toolkits will be tarred with the same brush.

Rick Jelliffe


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS