Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Generic constraints was: Re: RE: working with text
 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 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
