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]>
