[
Lists Home |
Date Index |
Thread Index
]
At 11:50 AM 5/12/2003 -0400, Amelia A Lewis wrote:
>On Mon, May 12, 2003 at 11:02:04AM -0400, Jonathan Robie wrote:
> >Of course, many of these same people are also writing essays explaining the
> >epistemological and geopolitical reasons that W3C Working Groups are not
> >listening to their great wisdom. One of the most basic reasons some of
> >these people are being ignored is that they are not making any specific
> >technical comments based on a careful reading of the specifications.
>
>That is, in part, because "specific technical comments" is a euphemism for
>"we don't have time to listen to criticisms of architecture; if you'd like
>us to change some of the decorations, speak up."
Specific technical criticisms of our architecture are certainly important -
"specific" does not mean "low-level".
>In my opinion, building the data model on the type collection thrown
>together in W3C XML Schema part two is a serious mistake (and yes, I *have*
>been reading the specs, and trying to figure out some of the really
>interesting nonsense like why asking for a date/time component returns it as
>GMT, instead of as its local/lexical reality). The working group in
>general, and some members in particular, would like to hear *specific*
>criticisms of *specific* types. Foo.
I think you may be misinterpreting what we are saying, at least if you mean
me when you refer to "some members in particular". I do think that specific
comments on the handling of specific datatypes is useful, but so is overall
discussion of larger design choices - as long as this is also specific and
technical.
> 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
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.
Most applications that need datatypes don't need much in the way of
datatypes. Many applications do need integer, float, decimal, string, etc.
Some W3C XML Schema datatypes are rarely needed, and there seem to be too
many of them. But these are all datatypes that we encounter in XML
documents - and not only in documents that are governed by W3C XML Schemas.
For simple datatypes, there's only one game in town. And that limits our
choices somewhat...and beyond that, our *requirements* force us to support
these datatypes. They also force us to support documents that do not
contain them, including merely-well-formed and DTD-governed documents.
>The "specific technical criticism" here is that tying XPath/XSLT (I don't
>much care what happens with XQuery, I think it has different requirements)
>to W3C XML Schema's collection of datatypes creates dangerous fragility and
>probably devalues the genuinely interesting innovations in XPath/XSLT 2.0,
>because they are too weighted with the freight of a type non-system.
Can you give me some examples of the kinds of fragility you are concerned
about? This is where specifics would be most helpful - I would like to make
sure that I understand precisely what problems you are concerned about.
Jeni has been pointing out some specific scenarios where she feels types
get in the way. More scenarios are welcome.
>Others
>have already proposed, as a specific technical solution, that a conformance
>level for XPath and XSLT that requires *no knowledge* of W3C XML Schema
>datatypes could be defined. That means that implementors don't have to
>build in the types so that the casting can happen. The working group has
>moved in this direction by permitting a conformance level in which the
>XPath / XSLT implementors do not need to actually parse schema.
XQuery doesn't require implementations to support Schema Import either.
There's really three issues:
1. Must an implementation support schema imports? Neither XSLT nor XQuery
require this.
2. In an input document, must an implementation be able to perform XML
Schema processing? So far, XSLT has been silent about how the data model
for an input document is built, and many people in the XQuery WG would like
to treat it this way in XQuery as well. There are some who disagree. I
expect hefty debate on this point in the near future.
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.
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.
>This suggestion
>effectively says "XPath 1.0 has a much more comprehensible type system than
>W3C XML Schema part two. We don't want to trade comprehensibility for the
>exceedingly dubious benefits of strong typing without a type system."
I'm not sure how you are using the term 'type system' in this email. XPath
1.0 had only four types, and W3C XML Schema has many more. I actually think
that the relationships among types and especially between typed and untyped
data are more carefully thought through in the XPath 2.0 and XQuery 1.0
specs - but looking at specific problem scenarios might be helpful here.
Cheers,
Jonathan
|
