[
Lists Home |
Date Index |
Thread Index
]
Uche Ogbuji wrote:
> >
> > >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.
> >
[...]
>
> 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.
>
I've been looking at the interface between XSDL/XQuery types and DAML+OIL =>
OWL (Ontology for the Web Language) classes. The current Semantic Web layer
cake layers OWL on top of RDF, but a number of people would like to just as
naturally layer OWL on top of XML instance data (I consider this a
requirement).
Toward this effort I have been thinking about a generic schema view that
incorporates XML Schema and RELAXNG into the OWL framework. This is on the
WebOnt issues list as discussed in
http://www.openhealth.org/WOWG/IssueStructuredDatatypes
More generally the field of "description logic" and UML are both two facets
on this same generic constraint mechanism.
Jonathan
|
