[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: limits of the generic

• To: "Simon St.Laurent" <simonstl@s...>
• Subject: Re: limits of the generic
• From: Uche Ogbuji <uche.ogbuji@f...>
• Date: Sat, 28 Sep 2002 14:32:25 -0600
• Cc: xml-dev@l...
• In-reply-to: Message from "Simon St.Laurent" <simonstl@s...> of "Sat, 28 Sep 2002 12:48:30 EDT." <r01050300-1015-1E5A588BD30211D68C880003937A08C2@[192.168.124.21]>
• Sender: uche.ogbuji@f...

> > 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
> framework.

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:

http://downloads.xmlschemata.org/python/xvif/xvif.html
http://www.advogato.org/proj/xvif/


> >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 
configurable.

> 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.  

<AOL/>


-- 
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 

• References:
  • Re: limits of the generic
    • From: "Simon St.Laurent" <simonstl@s...>

• Prev by Date: Re: limits of the generic
• Next by Date: Re: Datatypes - it's in the contract
• Previous by thread: Re: limits of the generic
• Next by thread: Re: limits of the generic
• Index(es):
  • Date
  • Thread