Lists Home |
Date Index |
> > You can derive from these examples that I consider the data typing to
> > be most useful for structured data types rather than for those that
> > could be compared as strings if the canonical lexical representation
> > were used.
> There are lot of other possibilities for conversion from lexical
> representation to structure that offer far more flexibility than the
> current system of predefined types. Regular fragmentations is one
> possibility, though I think Eric van der Vlist's xvif goes much further
> in making this kind of processing useful in a broader development
I must strongly agree here. XVIF seems to provide a very explicit way to
separate the layers, and express each with various technologies. I've started
playing with an extension element for 4XSLT that makes phases of XVIF
available within XSLT transforms. I think this would let in full data typing
in through the (nicely modularized) back door.
BTW, for those who wonder what we're talking about:
> >From my perspective, tossing W3C XML Schema's odd collection of types
> and facets from XPath in favor of smaller pieces of more configurable
> processing that takes place before XPath itself approaches the data
> would greatly simplify the implementation.
Right on the general point. But I'd say it could be before or after core
XPath operation, according to processing needs. Of course, XVIF makes this
> But I guess XPath 1.0 is already largely capable of handling that work,
> so it shouldn't do much harm for XPath 2.0 to continue its seemingly
> exponential growth.
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Apache 2.0 API - http://www-106.ibm.com/developerworks/linux/library/l-apache/
Python&XML column: Tour of Python/XML - http://www.xml.com/pub/a/2002/09/18/py.html
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/webservices/library/ws-pyth10.html