I think 1) is the right approach. All child elements inherit the namespace. The QNames of the children are in a sense "derived" values. Maybe that should not be stored in the children, but rather computed on demand, i.e. the methods on the children create a QName and return that. i.e. a copy is produced.
On 6/6/06, Jeremy Hughes <[EMAIL PROTECTED]> wrote:
I've been thinking about what Woden should do when the client code calls setTargetNamespace() on a populated DescriptionElement whose associated Description component is valid. Should: *1* the new targetNamespace propagate down to all the child components (at least ones with QName properties where the spec asserts their namespace is the targetNamespace)? Thereby keeping the Description valid? Or *2* should keeping the description component valid be a matter for the user code? Meaning the user is forced to write code to walk the Description tree updating the namespace of all the relevant properties. [In fact it is worse than that today, as we don't have setter methods on the component model API: the user must walk the DescriptionElement tree looking for the element or attribute associated with the component property and set the namespace in the Element model. Sometimes the setter won't let you set the namespace because the attribute is an NCName in the element model] I think the first choice is best so that as soon as targetNamespace is set on the DescriptionElement, all child components of the related Description which have properties asserted to be in the targetNamespace will change to the new targetNamespace. (ok I know this is side-effect programming, but the alternative is horrendous). I would also propose: *3* if the user is holding a reference to a child component of Description then changes the targetNamespace then the object he is holding a reference has the appropriate changes applied to it. Please post any thoughts around this ... especially if you have better design choices. Attached is source for a test case which fails today and which if *1* were implemented would pass. Thanks, Jeremy --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
