I've just created JIRA WODEN-29 for this [1] http://issues.apache.org/jira/browse/WODEN-29
Jeremy On 6/7/06, Arthur Ryman <[EMAIL PROTECTED]> wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
