[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Language Theorie concerning XML Schema (heavy,atleast

  • To: xml-dev@l...
  • Subject: Re: Re: Language Theorie concerning XML Schema (heavy,atleast to me)
  • From: Rick Jelliffe <ricko@a...>
  • Date: Mon, 02 May 2005 20:28:20 +1000
  • In-reply-to: <28237ff2a93b89f1ad69a26f3c20451c@w...>
  • References: <BBF4F4DF-0DDA-4E82-8F7C-8F80EA8E3856@h...> <1114548194.9178.165.camel@l...> <426F1628.6030201@m...> <642f07b6050427215328609939@m...> <427070FB.8030806@a...> <642f07b60504280007377ba5ac@m...> <642f07b60504280307755d53e@m...> <f5bd5sf6vm5.fsf@e...> <4270FECE.7050709@o...> <f5br7gu3m9w.fsf_-_@e...> <4271BDB4.80706@o...> <4271DCF8.7010202@a...> <28237ff2a93b89f1ad69a26f3c20451c@w...>
  • User-agent: Mozilla Thunderbird 0.6 (X11/20040502)

type theorie
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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.