[
Lists Home |
Date Index |
Thread Index
]
At 11:20 AM 5/7/2002 -0600, Uche Ogbuji wrote:
> > At 12:45 PM 5/7/2002 -0400, Simon St.Laurent wrote:
> >
> > >It's very useful because the representation doesn't _require_ you to
> > >process it in a particular way. The looseness of the representation (as
> > >Uche pointed out earlier) is actually a benefit for exchanging XML among
> > >diverse processing environments.
> >
> > Please illustrate this benefit with an example that is concrete enough to
> > evaluate. Show me an example where the typing of XPath 2.0 gets in your
> way.
>
>Better.
>
>The strong typing of XPath 2.0 makes it harder to understand and implement
>XPath 2.0.
This is true - especially the implementation part. I think the difficulty
in understanding is not as bad, once someone gets around to writing the
needed tutorials.
>Furthermore, the fact that XPath 2.0 has built in the concept of datatypes
>according to the XSDL canon forces out the development of generic typing
>for XPath.
>
>Your earlier example:
>
>avg( input()//person/salary )
>
>I have no problem with your being able to take advantage of the knowledge
>that in your application context, this can be verified, optimized, and
>treated in various ways as befit some useful physical representation of
>the data.
Good, I think this is a substantial area of agreement.
>Now, if I want to declare
>
><irrnum>3.14</irrnum>
>
>As an irrational number, and use the same capacity for verification,
>optimization, and treatment, can you tell me how to do so in standard XSDL
>and standard XPath 2.0?
>
>The answer is that you cannot. Why? Because I cannot write a standard
>constraint of irrationality, since the XSDL group in their wisdom decided
>this is not an interesting data type. I cannot even use their paltry
>extension mechanism for doing so. I cannot use standard facilities for
>the optimization that you trumpet so loudly.
This is true - and one of the reasons that I like schema extensibility
mechanisms like the Schema Adjunct Framework. With XML Schema, you can
currently define a type that allows you to represent an imaginary number
like this:
<irrnum><real>3.14</real><imag>0</imag></irrnum>
The problem, of course, is that this does not make it possible for XQuery
to compare two imaginary numbers. To make this possible, you have to tell
me how imaginary numbers are compared. Without schema extensibility, the
best you can do is to enter an additional piece of data giving the
comparison value. I think this is the distance from the origin for
imaginary numbers (my math is rusty), so I think this would be sqrt(3.14^2
+ 0^2), is that right? If so, that should be 3.14, so you have to create
elements like this:
<irrnum><real>3.14</real><imag>0</imag><dist-from-origin>3.14</dist-from-origen></irrnum>
Now you can use the distance from the origin to sort or compare.
Suppose we add extensibility to our schemas along the lines of the Schema
Adjunct Framework. We could then create a vocabulary for defining new
types. One thing we may want to specify is the way that a comparison value
is computed. Here is an adjunct to do that for this type, using the XQuery
language as the implementation language for the adjunct. I assume a math
library whose namespace is bound to the prefix 'math':
<type name="irrational">
<comparison-value> math:square-root( math:square( real ) +
math:square( imag ) ) </comparison-value>
</type>
In today's world, though, we don't have schema extensibility. That means
you don't get first class support for the semantics of user-defined types.
Still, having support for many very common types is better than not having
support for many common types.
>If we had a generic constraint mechanism, which might or might not be part
>of a schema definition language, and if this mechanism were modular enough
>not to overwhelm the basis of the XML specs that provided facilities for
>it, then I would have no complaint about addressing what I understand from
>this thread to be the sorts of use cases that drove XQuery, XPath 2.0 and
>XSLT 2.0.
I agree that a generic constraint mechanism, which is part of an extensible
type system, would be a Very Good Thing.
Jonathan
|
