[
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>
Don't you mean a complex number? Don't you mean
<complex><real>3.14</real><imag>0</imag></complex> ?
That's a problem of an entirely different order, and just has the benefit of being more amenable to *your* argument :-)
I think if you stick to irrational numbers, you'd see my point a bit better.
> 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.
This is where the philosophical part kicks in, and I do think that philosophy is very appropriate here. I take strong issue with your last sentence.
I would rather have a generic mechanism that allows developers to overlay their needed type systems. After all, it is developers that should be deciding what types are useful, not the XSDL group. Not even by delegation to Java folks who say "ya gotta have booleans" or SQL folks who say "ya gotta have int4 and int8".
My whole argument is that by picking these blessed types, ex cathedra, and then straining them through every XML spec in existence, that we end up removing the chance to make XML an effective bridge between all the various information management systems out there. Even the ones that we might not have happened to like.
> >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.
And all this effort on static typing is effort that would be better spent on a generic constraint mechanism. This is a value judgment, I know, but it is the crux of what I've been arguing all along. The second part of my contention has been that even a generic constraint mechanism should be treated in a modular fashion so as not to unnecessarily complicate the specifications that use it.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Track chair, XML/Web Services One (San Jose, Boston): http://www.xmlconference.com/
DAML Reference - http://www.xml.com/pub/a/2002/05/01/damlref.html
RDF Query using Versa - http://www-106.ibm.com/developerworks/xml/library/x-think10/index.html
XML, The Model Driven Architecture, and RDF @ XML Europe - http://www.xmleurope.com/2002/kttrack.asp#themodel
|
