*Shrug* OK, seems reasonable, David On Dec 8, 2007 3:42 PM, Saliya Ekanayake <[EMAIL PROTECTED]> wrote: > Hi David, > > I'm implementing XML Signature based on Axiom and I encountered many > situations where it requires a way to get the parent of an OMAttribute. I > agree with you that just because there is something in DOM we don't want to > put it into Axiom too. > > I liked the second approach basically because of that. Thus we don't throw > exceptions so the usage of an attribute instance in many elements is not > prohibited. Yet it guarantees that only a cloned is added inside. > > I firmly believe there should be a way to retrieve the parent from an > OMAttribute. The issue is what is the basis of keeping track of the parent. > If we enforce single parent constraint then it's obvious. But if we are to > allow an attribute to be added in more than one element then we are in some > trouble. > > I had to write methods manually to keep track of the parent while > implementing XML Signature and XML Canonicalization. It's IMHO is pretty > boring and ugly. > > Thanks for your idea > > --Saliya > > > On Dec 8, 2007 2:57 PM, David Illsley <[EMAIL PROTECTED]> wrote: > > > Um, IMO, this is really ugly... that DOM does something doesn't seem > > to be a reason for Axiom to do it. What is the driving use case that > > means you need this complication of the model? > > Cheers, > > David > > > > On Dec 8, 2007 5:44 AM, Saliya Ekanayake <[EMAIL PROTECTED]> wrote: > > > Hi all, > > > > > > Axiom implementation doesn't provide a method to retrieve the owner > > element > > > of an OMAttributeImpl instance. I've already created a JIRA on this > > issue > > > (see https://issues.apache.org/jira/browse/WSCOMMONS-230). I've resolved > > the > > > issue by adding an OMElement reference in OMAttributeImpl to keep track > > of > > > its owner. Thus I've provided a getOwner() method in OMAttribute > > interface. > > > > > > Now, I came across the issue of enforcing single owner restriction for > > > OMAttributes instances. Previously there was no constraint like that. > > The > > > patches I've send for the particular JIRA enforces this by means of not > > > adding the attribute to the element if its already used in another > > element. > > > This approach, however, tends to break Axis2 build because in Axis2 > > there > > > are incidents where attributes are being added to more than one element. > > > Thus I came up with two solutions to overcome this issue. > > > > > > 1. Throw a runtime exception (this is how it's done in DOM). Thus we are > > > sure that no two OMElements will contain the same OMAttribute instance > > (yes, > > > still we need to fix Axis2 code to not use attributes in more than one > > > element) > > > > > > 2. Create a new attribute with the same namespace, localname, and > > value. > > > Thus whenever a user tries to add an OMAttribute instance, which is > > already > > > used in an OMElement instance, to another OMElement instance that > > attribute > > > instance is cloned and its parent is set to the new element. > > > > > > I'm in favour of the second decision as it's more user friendly. The > > library > > > itself does the cloning process so that a user has to know only that > > it's > > > not the same attribute used but the cloned one. > > > > > > Your idea on this matter is highly appreciated. > > > > > > Thanks in advance, > > > > > > --Saliya > > > > > > > > > > > -- > > David Illsley - IBM Web Services Development > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > > -- > Saliya Ekanayake > http://www.esaliya.blogspot.com > http://www.esaliya.wordpress.com >
-- David Illsley - IBM Web Services Development --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
