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. 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. > > -- > Sylvain Wallez > Anyware Technologies - http://www.anyware-tech.com > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- "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]>
