Re: A proposed solution

> (and in fact it is the whole reason for the 
> existence of the list) that it was not clear:

I'd say the purpose of this list is to discuss changing that
text rather than clarifying it, but let that pass.

> I propose that we stay with the existing proposed text asis and
> clear up any misunderstandings before even starting to consider
> rewording.

But unfortunately the proposed wording is so vague that people can't
work out what the proposal is, Not just me either, note how Dan
Connolly couldn't interpret his test example against this proposal
without clarification.

If we accept your first argument above that what is needed is a
clarification of the spec, then the proposed wording _has_ to change
so that it is at least clear what the proposal is. Otherwise we'll
have a situation where everyone will accept a specification and then
go away and interpret it differently. Not that that has ever happened
before:-)


To reply to your specific points

> The              
> purpose of the phrasing above is to clarify that these properties are a
> function of the URI space and not of any particular URI. As questions  
> about this have been brought up in this very thread, I think this is
> relevant.

relevant to this list, which has discussed all sorts of things about
uris, but that doesn't necessarily mean it should be in a new spec.
Even after having it confirmed twice that it is not the case
I can not read that paragraph in that position in the text without
inferring that uri specific normalisation should be applied to
namespace names. It worries me that you show resistance to rephrasing
the proposal to avoid giving that impression.

> An application interpreting a document knows what it uses the namespace
> identifiers for.

This still seems like the "undefined" option to me, an application
can do what it likes, and different applications may do different
things? But somehow I suspect that isn't what you meant.
Perhaps I should wait until I see your response to James Clark's
rephrasing of the proposal into a form that I can understand.
I suspect that I could agree to some proposal based on one
or more of the variations he mentioned, but currently it takes a leap
of faith to be sure that agreeing to any of James' proposals is
equivalent to agreeing with the proposal that started this thread.



>    ignore them
>    use them for identification
>    use them for comparison
>    use them for retrieval

but conceptually before an application gets started worrying about
what to do with the document, a namespace aware XML parser has to
parse the thing, and answer the question what is the namespace and
local name of each element and attribute in the document.
Your proposal doesn't seem to answer that at all (as James Clark also
commented).


> It so happens that an application interpreting a single document at a 
> time - even with literal interpretation of the identifiers - is on safe
> ground wrt identification and comparison because it is within the same    
> context (not taking into account xml base but that it not relevant             
> here).                                   

As several people have pointed out an XML document can include several
external entities at different URI using XML 1.0 external entity
references so you hit a discrepancy with the current literal
interpretation even without xml base or xml include. (That maybe is an
acceptable price to pay, but it needs to be documented.)

David

Received on Saturday, 10 June 2000 14:57:14 UTC