Lists Home |
Date Index |
> John Cowan and I have been pushing around the idea that it should be a
> requirement on 'official' infoset extensions that they come with a
> serialisation. I'd like to see this happen, for example along the
> lines of the various reflections Richard Tobin and I have explored for
> the PSVI. It would be a simple step to allow XPaths to navigate
> extensions via a pretend reflection. All that's required is a
> function 'reflect(property)', whose value would be a reflection of the
> value of an infoset property of the current node. So, for instance,
> to access the appinfo annotation of the type used to validate an
> 'apple' element child of the current node, you'd say:
> You could of course navigate the vanilla infoset this way. The
> equivalent of /*/apple/@banana would look like
I have been slow to come to agreement. I've always thought there should be
many alternative ways to represent the Infoset, but I think in light of the
whole XPath discussion, that I do finally agree. A standard serialization for
Inforset extensions, based on the XPath 1.0 data model, or minor extensions
thereof, could be a lynch pin for an annotation and declarations framework for
That having been said, I hope we don't end up with the horrible name "reflect"
for the function. I've always hated the terms "reflection" and
"introspection" in their current CS sense because of their meaninglessness in
the light of general English usage.
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.
Python/Web Services column: xmlrpclib - http://www-106.ibm.com/developerworks/w