I was under the impression after reading the w3 namespace spec that the
prefix is only used for selecting the namespace URI. The URI + localpart
is what determines equality, correct? It is legal XML to have two
different element prefixes bound to the same URI. I believe what you are
referring to is section 5.3 (uniqueness of attributes). It is illegal for
an element to contain qualified attribute names bound to the same
namespace uri, i.e.
<parent xmlns:ns1="/uri" xmlns:ns2="/uri">
<bad ns1:attribute="foo" ns2:attribute="foo"/>
</parent>
Regards,
--mike
On Fri, 9 Nov 2001, Berin Loritsch wrote:
> Peter Donald wrote:
> >
> > On Sat, 10 Nov 2001 09:23, Berin Loritsch wrote:
> > > Peter Donald wrote:
> > > > On Sat, 10 Nov 2001 01:23, Sylvain Wallez wrote:
> > > > > Berin Loritsch a �rit :
> > > > > > I want to clarify if everyone is happy with the Namespace
> > > > > > class. We need to take care of it NOW before it is too
> > > > > > late!
> > > > >
> > > > > Namespace info and Configuration names are OK for me, but a few
> > > > > questions about the prefix validation in Namespace.equals() :
> > > >
> > > > what is validation meant to do ? Neither the policy or m_validate_prefix
> > > > seem to be used.
> > >
> > > Hmm.
> > >
> > > Ok the policy is supposed to be a flag to use the prefix during
> > > comparisons of Namespace objects or not.
> > >
> > > I.e.
> > >
> > > pre1:element
> > > pre2:element
> > >
> > > Where pre1 and pre2 are set to "test-uri/namespace"
> > >
> > > With m_validate_prefix set to true, the two namespaces would be
> > > considered different. So .equals() would return false.
> > >
> > > With m_validate_prefix set to false, the two namespaces are
> > > considered the same (the all important URI is the same). So
> > > .equals() would return true.
> >
> > when would you want validate_prefix to be set to true? Doesn't that violate
> > basic principles of XML ? So I can think of a place I would like to use it
> > but then again that case is an ugly hack. Is there any legitimate uses for
> > this? ;)
>
> According to the XML Namespace spec, officially the namespace is different
> if the prefix is different. Of course, I may be applying something only
> meant for attributes to elements.
>
> In the end, I would like them to be treated the same even if the prefix
> is different--but that could have been accomplished by removing the
> Namespace object and ONLY keeping the URI in the configuration.
>
> > > > > - is this good to have a static setting for this policy in a
> > > > > multi-thread/multi-app environment ?
> > > >
> > > > probably not.
> > >
> > > How often do you create new Namespace objects?
> > Every time you create a Config tree ;)
>
> Usually done in one thread at init time.
>
> > > Also, wouldn't you
> > > want the same policy accross the board?
> >
> > no.
> >
> > Example: when ant2 goes live and I finally commit my jobserver,
> > ant2/jobserver will possibly be using a different policy than main
> > phoenix.
>
> I see.
>
> > > The Factory methods (.getNamespace(String)) can be extended to
> > > simply have a boolean to set the policy for the object.
> > >
> > > However you must keep in mind that multiple policies for comparing
> > > Namespace objects has unpredictable results. (actually it will
> > > use the policy of the Namespace object on the left side of the
> > > argument).
> >
> > you probably shouldn't be comparing namespace objects across domains anyway
> > -
> > I would consider that an error in the code.
>
> So does the change to the factory method sound like the way to go?
>
>
>
> --
>
> "Those who would trade liberty for
> temporary security deserve neither"
> - Benjamin Franklin
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
