On 9/30/02 1:20 PM, "Matt Gushee" <mgushee / havenrock.com> wrote:

> On Mon, Sep 30, 2002 at 11:08:15PM +0900, Bob Hutchison wrote:
>> On 9/27/02 11:18 AM, "Volkmann, Mark" <Mark.Volkmann / AGEDWARDS.com> wrote:
>> 
>>> In my case I'm given a string which is a namespace prefix and I want to
>>> determine the namespace it is associated with.  I don't have an Element
>>> object
>>> so I can't use the namespace method.
>> 
>> XML namespaces are defined as xml is processed. The prefix may be reused.
> 
> You mean 'prefix-to-namespace mappings are defined ...', don't you? Sorry
> to be picky, but XML namespaces are confusing enough without imprecise
> explanations.

I guess I meant both.

I should also have said 'namespace2' in element2 in my example.

You are right, it is confusing enough (and it doesn't matter how precise you
are, it is still confusing)

> 
>> <element1 xmlns:N='namespace1'>
>>     <element2 xmlns:N='namespace1'/>
>> </element1>
>> 
>> is legal (though a questionable practice, and ignoring opinions w.r.t.
>> Namespaces being URLs). In this example there are two namespaces but only
>> one prefix is used. In general, the prefix mapping to namespace is scoped.
>> This makes it impossible to answer the question you want to ask unless you
>> can identify a spot in the document.
> 
> I would say 'unreliable' rather than 'impossible'. You're quite right
> that it's legal to reuse prefixes, but it would be very counterintuitive
> to do so, and I doubt that it's likely to happen in practice; I've
> certainly never seen it (except in examples contrived to show that it
> can be done). Have you?

Yes, actually, I have. I certainly don't recommend the practice, but I've
seen it. If you are writing tools for XML you have to be prepared for it.

> 
> Which means that, if a certain degree of doubt is acceptable (e.g. doing
> a first-pass analysis of a large collection of XML documents, with
> thorough testing to take place later), there shouldn't be a problem with
> just pulling out the first available mapping (though I don't think I'd
> choose that approach myself unless I were under extreme time pressure).

I wouldn't recommend it.