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. > 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. > 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. > 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. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
