[
Lists Home |
Date Index |
Thread Index
]
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> / John Cowan <jcowan@reutershealth.com> was heard to say:
> [...]
> | Again, the mere *provision* of typing metadata does not prevent such reuse.
> | However, if *standard tools* assume that the metadata is sound, then
> | transgressive reuse may indeed be made difficult. Obviously, purely lexical
> | tools are not affected, but tools based on XQuery/XPath2/XSLT2 will not
> | be purely lexical in this sense (whereas XPath1/XSLT1 are).
>
> Taking the specific case of XQuery/XPath2/XSLT2, I'm not sure I see
> the problem. Given
>
> <baz>
> <foo n="1">Network Drive</foo>
> <bar moo="0902">01803</bar>
> </baz>
>
> I might write a template that matches those elements in a purely
> lexical way.
>
> <xsl:template match="baz">...</xsl:template>
>
> I might also write a template that matches them based on some data
> type (forgive the psuedo-xsl, the standards are still fluid as you
> pointed out):
>
> <xsl:template match="*[type() = my:AddressType]">...</xsl:template>
>
> The latter case seems to be exactly what Walter Perry described in an
> earlier message on this thread: a particular view of the data in a local
> context (I wrote the query that way because I expect to interpret the
> darned thing as an address).
>
> Imposing my view on the data for my query doesn't seem to do any harm.
>
> Or are you concerned that I'm going to slurp up the XML, interpret it
> according to my local context, shove it into some database somewhere
> with those interpretations and thereafter be unable to view it with a
> different local context?
>
> Some people are going to do that, I suppose, to bend XML to the will
> of their databases. But I'm not going to do that (that would be
> stupid, IMHO, but I'm not trying to build a system that processes a
> zillion purchase orders a minute, either). I haven't perceived anyone
> threatening to force me to do that. Am I insufficiently paranoid?
>
> Or have I missed the point?
I think you may have missed the point, because as far as I see it, you're
using data types in a very modular fashion: i.e. at the precise point in
processing where it is immediately useful.
I think that no one objects to such use of data types.
The problem I bring up is that in their very tight coupling to text-based XML
processing specs, that WXSDT end up pretty much imposing implicit data typing
even when it is not needed, and when it can hamper the processing. In order
to use these new data typing "wizards" (as Jonathan call them, seemingly
deadpan), you have to build these data types into the schema or the instance,
which means they now affect all XPath, XSLT and XQuery operations on them.
This, I think is where the brittleness emerges.
As I've said many times I have no problem with data typing qua data types. I
do object to
* The bias towards static types
* The lack of modularity in W3C efforts to incorporate data typing into XML
technologies
In other words, to return to trope: I dislike the fact that things are
permanently stamped with their class for all their lifetime, and that their
class is considered an intrinsic part of their being. That's so, like, fuedal.
--
Uche Ogbuji Fourthought, Inc.
http://uche.ogbuji.net http://4Suite.org http://fourthought.com
Tour of 4Suite - http://www.xml.com/pub/a/2002/10/16/py-xml.html
Proper XML Output in Python - http://www.xml.com/pub/a/2002/11/13/py-xml.html
RSS for Python - http://www-106.ibm.com/developerworks/webservices/library/ws-p
yth11.html
Debug XSLT on the fly - http://www-106.ibm.com/developerworks/xml/library/x-deb
ugxs.html
|
