[
Lists Home |
Date Index |
Thread Index
]
On Mon, May 12, 2003 at 02:02:18PM -0400, Jonathan Robie wrote:
>At 11:50 AM 5/12/2003 -0400, Amelia A Lewis wrote:
>> I want a type system. The specs have
>>moved in this direction, but not far enough, in my opinion.
>
>Let me make sure I am hearing you correctly - you seem to want a better
>collection of simple types. Are there other things that you are asking for
As you point out, it doesn't exist. I would add "yet."
>when you say you want "a type system"? As far as I know, there is only one
>widely accepted set of simple datatypes - the W3C XML Schema datatypes are
>used in (at least) W3C XML Schema, many RELAX NG applications that import
>them as a type library, RDF, and the SQL/XML mappings from SQL to XML
>views. When XQuery or XPath are applied to documents, they encounter more
>than a few documents that contain these types.
>
>With respect to these types, we have two basic needs:
>
>1. XQuery needs to know how to handle typed data when it is encountered in
>documents.
>2. XQuery needs types like integer, float, and string for its own
>expression language.
Okay. I *do not* challenge XQuery's necessities. I wish to challenge the
introduction of the complexities of the use of the W3C XML Schema datatype
collection into XPath and XSLT.
(I believe that reliance on the W3C XML Schema datatypes definition makes
XQuery potentially fragile, but we can discuss that below).
I do not think that XPath or XSLT need the complexity of W3C XML Schema for
datatypes. Moreover, the difficulty of that spec (WXS part 2), its
incompleteness, and its rigidity (can only be changed by taking hat in hand
to the committee) significantly impedes comprehension of any specification
that *requires* it (such as XPath/XSLT 2.0). It may also have significant
performance impact; unknown at the moment. When users' and implementors'
requirements are significantly more broadly defined (need "number" and
"boolean" and "node" (or "sequence" or whatever, an XML thingy) and
"string", and probably "date"), enforcement of the incomprehensibility
expressed in the W3C XML Schema spec is a genuinely bad thing.
The kindest description I've heard of the W3C XML Schema datatypes
collection is "baroque". The most accurate is perhaps "baroquen".
Having had responsibilities for explaining this mish mash to people who are
not thrilled with XML in the first place, I am strongly of the opinion that
sooner or later someone is going to come along with a type *system*
definition for XML. Perhaps it will be DSDL (although it seems that they
also want to start from types-as-used-in-languages, rather than what XML can
say about types). We'll see. When that happens (that is, when a type
system is introduced, characterized by consistency, completeness, and
comprehensibility), I think that the W3C XML Schema collection will be of
historic interest only ... and so will all the specifications that were
built in such a way that the *only* types they can use are those defined in
W3C XML Schema part two. At the moment, that seems to include all the
specifications in process for the XPath/XSLT/XQuery working group. I keep
hoping that the only spec made so irrelevant is XQuery (although it would be
nice to see an abstraction layer able to remove the dependency on WXSp2
types for XQuery as well ... but *that's* more than merely unlikely).
>Most applications that need datatypes don't need much in the way of
*sigh* We've immediately parted company, in effect.
XML can't say much about datatypes, because it is a storage and transmission
format. So it can say something useful about the validation algorithm. Any
datatype MUST be defined with a validation algorithm, which defines how the
datatype further subsets the base text node validation (let's call that
xmlstring), permitting only text that represents valid instances of the
type. Probably a type definition should also specify rules for
comparison/collation, which enables a lot of what one needs or wants to do
in XPath/XSLT. Beyond that, once one begins to talk about operations
permitted, I would argue that XML makes no assertions, and a type library
ought not provide anything more than guidance.
>For simple datatypes, there's only one game in town. And that limits our
For now. I think that depending on the hope that this will always be true,
given my own (and others' reported here) experience in trying to explain
this stuff, is short-sighted.
>choices somewhat...and beyond that, our *requirements* force us to support
*shrug* XQuery's requirements do. I haven't read the requirements drafts
(focused on xpath, funcs & ops, data model, and xslt). If XPath and XSLT
have the requirement, then perhaps we can just give up, see what interesting
ideas can be pulled from the result, and apply them to an alternative
development.
>Can you give me some examples of the kinds of fragility you are concerned
That as the problems surrounding the WXS definition of simple datatypes
become more and more noticeable (as more and more people have to explain the
damn things, and justify the unjustifiable), it will be replaced, and specs
that can only deal with types as defined by WXS will fail as well.
Note that RNG found a way around this problem, by defining plugin datatype
libraries. This is harder if one is defining the entire corpus of functions
and operators. It *can* be done, though, or so I believe. On the other
hand, Michael Kay is likely to throw me overboard for suggesting it, and row
harder ....
>3. Is there a relationship between the types of XQuery literals and the
>types in XML documents governed by schemas? XQuery needed to have integers.
>W3C XML Schema has integers. If we let both be the same type, this
>simplifies a lot of things.
At present, the WXS definition is the only legal integer. That's the
problem. However, I think that you're speaking specifically of XQuery, and
I'm less concerned about that than about the underlying stuff, particularly
XPath.
>I'm not sure if you are asking that there be a level in which XPath does
>not have integers, or in which there is no relationship between an XPath
>integer and an integer in an XML document, or merely that an implementation
>should not be required to do XML Schema processing to determine which items
>are integers in a document.
Approximately the latter, I think. I don't quite understand your
distinctions.
I would rather see XPath able to say "integer" or even simply "number", and
let it be mapped to *any* type library's definitions.
>I'm not sure how you are using the term 'type system' in this email. XPath
"Type system: nominal phrase. What W3C XML Schema part two doesn't define,
when it defines datatypes."
"Type system: nominal phrase. A complete or completable, consistent, and
comprehensible division of data into 'types' or 'categories', in which each
'type' has common (usually well-known) behavior. In XML, only validation is
of concern. Some XML-related languages introduce additional requirements
for type definitions, such as algorithms for comparison."
>specs - but looking at specific problem scenarios might be helpful here.
Problem: explaining W3C XML Schema's gHorribleKludge to newbies so that they
can use dates in a stylesheet transformation. Please shoot me first, okay?
I actually *have* such a presentation, one that interpolates an abstract
date type between "ur" and gHK (which reduces the number of unrelated
things, and thereby increases comprehension, if only slightly), but *how*,
please let me know, do I explain to newbies that float and double aren't
numbers?
Amy!
--
Amelia A. Lewis amyzing {at} talsever.com
And now someone's on the telephone, desperate in his pain;
someone's on the bathroom floor, doing her cocaine;
someone's got his finger on the button in some room--
no one can convince me we aren't gluttons for our doom.
-- Indigo Girls
|
