[
Lists Home |
Date Index |
Thread Index
]
Uche Ogbuji:
> [...]
> |> 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.
Norman Walsh:
> Who or what is preventing you from using them that way? (I'm really
> not trying to be argumentative, I think I'm a bohemian myself, and I
> sometimes think the gentry go a little bit off the rails, but I don't
> lose sleep over it because I don't see how I'm being threatened. As I
> said before, maybe I'm insufficiently paranoid.)
So read on...
> | 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.
>
> Where is the tight coupling? Schema import into a stylesheet or XML
> Query will bind them together, but I think that's an instance of
> modular use. That doesn't bind my documents to any particular schema
> (except perhaps when I run a particular query, naturally).
Two things:
1) From my last reading of XPath 2.0, schema "import" was not optional if the
document had a PSVI. If this has changed, this is a big step forward.
2) Even if schema import is optional, it is all or nothing. More likely, I
want to use type information in, say, one template, and not across the board
for all values.
So I (possibly) have tight coupling, and too clumsy granularity. Both are
problematic, and don't correspond to modularity for me.
> | 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,
>
> Building data types into the schema doesn't seem harmful. That's the
> point of a schema, is it not?
My point is that it ensures tight coupling.
> I'm not sure what you mean by building the data types into the
> instance. If you mean using xsi:type,
Yes. That's what I mean.
> then I agree completely that
> it's brittle. And wrong. And I'll quickly discard any tool that does
> it.
I'm curious: Why do you think it is more wrong than building it into the
schema? Not that I disagree...
> | which means they now affect all XPath, XSLT and XQuery operations on them.
> | This, I think is where the brittleness emerges.
>
> Sometimes I write stylesheets that are entirely data type agnostic,
> but not really very often. I don't see how building data typing into a
> particular stylesheet or query is harmful.
I didn't say building it into a particular stylesheet or query is harmful. I
said that if the data typing info in the PSVI is used at the basic XPath
processing info, that this is harmful, except in skilful hands.
> | * The lack of modularity in W3C efforts to incorporate data typing into XML
> | technologies
>
> Do you mean because they're tied more-or-less exclusively to WXS? Or
> do you mean something else?
Bound to PSVI, to be specific. And I also mean that there hasn't been enough
work in defining profiles that define generic processing (including
constraints processing) for those who don't want static typing.
> | 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.
>
> What is "all their lifetime"? If I drag a stream of bits off my disk,
> subject it to schema validation, and build, for example, an XPath2
> Data Model instance out of it, those types will be stamped on the data
> model. But the chances are pretty good that I'm going to use that data
> model to do some particular process on the document and then throw it
> away.
Maybe. I didn't say that it is impossible to use data types soundly.
--
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
|
