XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] The <any/> element: bane of security or saviorofversioning?

 
> By the way, I think the XSLT2 conformance is wrong if it 
> doesn't include the built-in derived types. Users often don't 
> understand the type hierarchy, and it promotes the nominal 
> hierarchy of the built-in types into being something real 
> whereas it is just a theoretical artifact and something to 
> help implementors. 

We had a lot of toing and froing on whether the built-in non-primitives
should be included in the basic conformance level. Such decisions are always
a bit arbitrary. 

I've got a personal dislike of many of the derived types - the integer
subtypes are horribly hardware-oriented, whereas I think people should use
types that relate to the application domain; and the string subtypes are
mainly useful if your data happens to have the syntax of XML names, which I
would consider unusual (there isn't even a built-in subtype for strings that
can't contain spaces, which must be about the most common requirement of
all.) So I would tend to say, if you want derived types at all, then you
probably want to define your own, which means you're in schema-aware
territory.

But that's not why they weren't included. It was more a desire to simplify
things for users and for implementors.

Michael Kay
http://www.saxonica.com/



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


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

Copyright 1993-2007 XML.org. This site is hosted by OASIS