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

Re: Who can implement W3C XML Schema ?

  • From: "Simon St.Laurent" <simonstl@s...>
  • To: Eric van der Vlist <vdv@d...>
  • Date: Thu, 25 Oct 2001 08:56:27 -0400

using anysimpletype msxml
On Thu, 2001-10-25 at 03:00, Eric van der Vlist wrote:
> I been thinking about all this and regular expressions could definitely 
> play a more important role in the definition of so called simple types.
> 
> The general framework of W3C XML Schema part 2 is, IMO, good. The main 
> limitation and probably the main source of complexity is that, instead 
> of defining a few simple generic mechanism, the rec is defining 10+ 
> opaque primitive datatypes each of them using different algorithm which 
> are only described as text.

That "limitation" is precisely what I see as the "general framework" on
which XML Schema is based.

> If you look at the processing <disclaimer>as I understand it 
> now</disclaimer>, you get a chain of several transformations between 
> several "spaces" and these transformations which are "hard coded" could 
> have been defined using a "datatype toolbox" which could have been 
> specified in a language independent fashion like XPath has been defined.

Yes.

> The first transformation is between what I call the "parser space" (what 
> a XML 1.0 parser sends to an application) and what W3C XML Schema calls 
> the lexical space.
> 
> This transformation is currently only dealing with additional whitespace 
> processing and it regular fragmentations would have been, IMO, really 
> beneficial at this level.
> 
> There is then a second transformation which is converting the lexical 
> space into value spaces and, here again, instead of defining a dizain of 
> "opaque" transformations, these transformations could have been defined 
> using a library of binding functions (such as toInt, toDate, toList, 
> toArray, namespaceURI, localName, ...) which could have been combined 
> together.

Part of what I find difficult about the datatypes specification is the
lack of discussion about such processing.  There seems to be an
assumption that only mapping is happening, and that somewhat magically.
Where XML 1.0 talks perhaps too much about processing, XML Schema Part
2: Datatypes barely acknowledges processing.

> A common mechanism might be used for the two transformations if the 
> regular expressions are defined through "regexp" functions and these two 
> steps might even be defined in a coherent way.
> 
> With such a framework, a single primitive type would be enough 
> (anySimpleType) and all the predefined datatypes could be defined 
> programatically using the function library.

That would produce a solution I would find more workable. 
Unfortunately, I suspect the damage to the XML ecosystem is already too
substantial for simple replacement of this spec with another.  As a
result I'm defining Regular Fragmentations as an alternate but
(potentially) complementary framework, not as a direct competitor.

> This would have allowed to meet the needs for internationalization and 
> for new types such as arrays which are not covered by W3C XML Schema.

It would have addressed a much wider set of needs, with potentially less
complexity.  (Mechanisms seem to be more complex than descriptions, but
when I read xmlschema-dev on whitespace and notations, it's hard not to
wonder if this situation is one where mechanisms are more appropriate.)

> This might be seen as more complex, but I think, on the contrary, that 
> it's always simpler to describe a few generic concept and use them to 
> build complex structures than to describe these complex structures with 
> plain text.

I'm not sure that's true as a general rule, but I think they've built
too much on too little here.

> When these types have been defined (either predefined of by the user), 
> restricting by facets is OK. And having this library of functions at 
> hand would have allowed to define the facets more generically as assertions.

Right - facets still do well at definining constraints, and an assertion
model would make sense to me at least.
 
-- 
Simon St.Laurent
"Every day, in every way, I'm getting better and better." - Emile Coue


PURCHASE STYLUS STUDIO ONLINE TODAY!

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.
Email
First Name
Last Name
Company
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.