Sylvain Wallez wrote:
>
> Berin Loritsch a écrit :
> >
> > Sylvain Wallez wrote:
> > >
> > > Berin Loritsch a écrit :
> > > >
> > > > Sylvain Wallez wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > > I've tried to use the new namespace-aware Configurations and
> > > > > encountered
> > > > > serious problems : each Configuration is given the latest namespaces
> > > > > declared whatever its actual namespace is.
> > > > >
> > > > > For example :
> > > > > <?xml version='1.0'?>
> > > > > <ns2:config xmlns:ns1='namespace-1' xmlns:ns2='namespace-2'>
> > > > > <ns1:child name='child-config'>
> > > > > <foo>value of blah</foo>
> > > > > </ns1:child>
> > > > > </ns2:config>
> > > > > leads to all elements being marked as belonging to "ns2" (the latest
> > > > > one
> > > > > declared).
> > > > >
> > > > > So please find attached a patch for both SAXConfigurationHandler and
> > > > > DefaultConfigurationSerializer.
> > > >
> > > > I would like to apply them, but I need the source to NamespaceSupport.
> > >
> > > org.xml.sax.helpers.NamespaceSupport ;)
> >
> > I figured that out after I sent the message. Doh!
> >
> > > > > But there's another important issue : configurations are given the
> > > > > prefixed name of the XML element (e.g. "ns2:config" and "ns1:child").
> > > > > I
> > > > > think this is wrong : namespace prefix is only XML syntactic sugar and
> > > > > doesn't have any semantic meaning (you can give any prefix to a
> > > > > namespace). Having prefixed names obliges either the configuration
> > > > > file
> > > > > to use predefined XML prefixes (we've seen on Cocoon how error prone
> > > > > this can be) or the application to manually strip prefixes when
> > > > > processing the configuration.
> > > >
> > > > Keep in mind that each prefix:uri combination is unique in XML.
> > > >
> > > > <root xmlns:ns1="namespace" xmlns:ns2="namespace">
> > > > <element ns1:foo="bar" ns2:foo="baz"/>
> > > > </root>
> > > >
> > > > Notice in the above, ns1:foo != ns2:foo.
> > > > They are unique and independent attributes as far as an XML parser is
> > > > concerned, therefore the above markup is legal. If they were both
> > > > ns1:foo attributes, the above markup would not be legal.
> > >
> > > Agree. But in the above example, how would you know what are the URIs
> > > associated to "ns1" and "ns2" when handling the attributes of the
> > > "element" Configuration object ? I'm afraid there is no solution with
> > > the current Configuration interface since attributes aren't represented
> > > as objects that could have an associated URI. And having an Attribute
> > > class would turn Configuration nearly into a lightweight DOM
> > > implementation...
> >
> > I don't want that.
>
> Neither do I, so maybe a solution is to have an additional constraint on
> XML configuration documents : local attribute names must be unique, even
> if their namespaces are different. This isn't really restrictive and can
> easily be checked by SAXConfigurationHandler. We could then use local
> names for attributes also.
>
> > I displayed that as a way to demonstrate that it is useful to have the
> > prefix as well. Again, Configuration should not support every feature
> > of XML.
> >
> > > > > What I propose is that a Configuration object is given the local XML
> > > > > element name (no prefix) and only has the URI as namespace
> > > > > information.
> > > > > The Namespace class could even be removed.
> > > >
> > > > This is an option. We do want it to be clear that just because we
> > > > support
> > > > XML markup, that we do not support every aspect of it. For example,
> > > > the XML must be Structured--not semi-structured.
> > >
> > > Agree. This is also why I suggest prefix to be only a serialization
> > > hint.
> >
> > When I applied the change, the name of the configuration element did not
> > have the prefix information in it. That is as it should be.
> >
> > > > > The only use I can see for the prefix is for XML serialization. We
> > > > > could
> > > > > either :
> > > > > - have the serializer auto-generate prefixes (ns1, ns2, etc), possibly
> > > > > with the help of a Map of default prefix/URI mappings,
> > > > > - keep prefixes in Configuration only as a serialization hint. But
> > > > > application code using Configuration objects shouldn't have to worry
> > > > > about it, meaning as above automatic prefix generation for
> > > > > Configurations created by the application.
> > > >
> > > > The consept behind the Namespace object was to maintain the prefixes
> > > > that
> > > > the administrator chose, but only use the prefix as a serialization
> > > > hint.
> > > > Granted that can be accomplished by making the getPrefix() method
> > > > protected.
> > > > But then you are stuck with the ConfigurationSerializer in the
> > > > configuration
> > > > package.
> > >
> > > It could be public, but clearly identified as being a hint and allowed
> > > to return null.
> >
> > The current implementation does not return null, but an empty string. That
> > way
> > we avoid NPE all over the place--and can simplify if/then/else statements.
>
> Mmmh... IMO, null and "" have different meanings :
> - null means no prefix is associated with the Configuration object and
> the serializer must determine the actual prefix, either by checking
> already declared prefixes (NamespaceSupport makes this easy) or by
> generating a new prefix.
> - "" means the namespace is the default one like in <foo
> xmlns="foo-namespace"/> and is a valid value for the prefix.
Keep in mind, this is what the Namespace Aware parsing does. You never have
null namespaces. It is either default (xmlns="") or specified.
--
"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]>
