Re: [xml-dev] Who can implement W3C XML Schema ?

["Simon St.Laurent" <simonstl@simonstl.com>]

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