[
Lists Home |
Date Index |
Thread Index
]
> 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
|
