OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Generic constraints was: Re: [xml-dev] RE: working with text

[ Lists Home | Date Index | Thread Index ]

Uche Ogbuji wrote:

> >
> > >Furthermore, the fact that XPath 2.0 has built in the concept of
> > >according to the XSDL canon forces out the development of generic
> > >for XPath.
> > >
> > >Your earlier example:
> > >
> > >avg( input()//person/salary )
> > >
> > >I have no problem with your being able to take advantage of the
> > >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
> > >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
> > >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
> > >of a schema definition language, and if this mechanism were modular
> > >not to overwhelm the basis of the XML specs that provided facilities
> > >it, then I would have no complaint about addressing what I understand
> > >this thread to be the sorts of use cases that drove XQuery, XPath 2.0
> > >XSLT 2.0.
> >
> > I agree that a generic constraint mechanism, which is part of an
> > 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

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

More generally the field of "description logic" and UML are both two facets
on this same generic constraint mechanism.



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS