[
Lists Home |
Date Index |
Thread Index
]
Yes, yes, locality is good. Normally, I don't care what some server thinks,
I worry about what my processes and users think about the data.
But isn't XPointer a different case?
My understanding of XPointer's mission is "to define the fragment
identifiers for the text/xml mime-type".
If we want to preserve the universality of URLs, there should be a
consistent meaning for the fragment identifiers. Giving them a different
meaning based on what XML Schema is used reminds me of the earlier proposal
that namespace/prefix bindings depended on the context of the reference. I
think this idea should be rejected for the same reasons.
Yes, I know how it works with DTDs. But users of documents processes them
using the DTD specified by (or even internal to) the instance. They don't
load up a random DTD of their choice and use it instead - if they do they
expect certain things to break, such as fragment identifiers.
-Wayne Steele
>We could do that, but it would be wrong (in my view). Wrong because
>it violates locality -- a barename link with name XYZZY is to what the
>_target_ establishes as is its XYZZY ID, not the source. Think of how
>it works with DTDs, and a complex case with external entities and
>catalogues and proxies and . . . There's nothing I can do at the
>source end to determine what the target is going to establish as the
>referent under those circumstances. So I don't think there should be
>for the Schema case either. The _user_ does that by setting up the
>processing environment, in either case.
>
>ht
_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail.
http://www.hotmail.com
|
