[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: limits of the generic
> Hi Uche, > > > This is true. I guess if you put it in that light, I can consider it > > with a more friendly eye. I know that XVIF has been designed from > > the beginning to support generic lexical processing. I guess that's > > been what Jeni has been trying to do as well, but it looked as if > > her example was couched in the sense of defining a set of operations > > and lexical mappings tailored to WXS types. Perhaps I was too hasty > > in that judgment. > > Right, sorry I wasn't clearer. I wasn't aiming for W3C XML Schema > types -- I was writing to string, number and boolean -- the core types > for XPath 1.0. You were probably clear, and I was probably reading with blinkered eyes. > > So, starting afresh on this idea, and expressing it in XVIF, which > > has the advantage of a handy implementation right now, > > Well, I thought that XSLT had a few handy implementations around, and > the advantage that I know the language, so I thought I'd use that. I > think that ideally these data type definitions could be written in > *any* language, and it would be up to the processor to support > whichever language they wanted. OK. I can go for an XSLT expression just as well. I've been workign with XVIF in 4Suite, so to me it was the quickest path to possible experimentation, but I agree that finding a more universal expression, such as XSLT, is a good thing. > > This does only answer one of my complaint: generic dispatch and > > constraint processing. That is a big bone of contention, so I'd be > > happy for such a solution, but the fact is that it still introduces > > a lot of complexity, which is worrisome. > > In terms of the operations, I think that a lot of the complexity (from > the user side) can be managed by having sensible defaults. For > example, if a data type doesn't offer a specific equals definition, > then the application could turn it into a string and compare it as a > string. Makes sense. > > However, if it is inevitable that the data types juggernaut must > > have its stone of flesh in the end, I would rather a mechanism such > > as the above allowed others to put their own data types on an even > > keel, and also allowed other forms of axiomatic processing besides > > data types. I also like that it expresses value space operations as > > simple transforms on the plain lexical information, which is an > > important assertion of layering. > > OK. Can you describe more about what you mean by that? Well, I think the nub of it is that if we come up with an expression mechanism for data type bindings, as we've been discussing, that such a mechanism should be powerful enough to express constraints and behavior more broad than just data typing. As a rough example, I would like to be able to express that in some instances, the addition of two numeric types should have the result rounded to the nearest whole number, even if this special mode of addition is not native to that data type. Yes, this could be done by separate + and round() ops, which is why I admit it's a rough example. -- 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/w ebservices/library/ws-pyth10.html
|
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
|