John, The XML Parser (DOM implementation) has been completely replaced in Witango 5.5. This is separate to the DOM manipulation technologies XPointer and XPath that have nothing to do with the parsing of the XML at all and are in the next layer out from the DOM implementation and XML parsing.
We do use Xerces in Witango 5.5 to provide the XML parsing and DOM implementation for both XPointer and XPath. The problem is that Xerces does not have a XPointer implementation. To provide backward compatibility with existing Witango 5.0/T2K applications we took the Witango 5.0 XPointer implementation and modified it to use the Xerces DOM. XPointer and XPath just assume that a DOM is available (they don't care how it is created) for them to process as they work only with the object hierarchy. As Ben suggests there were a lot of historical issue with the XPointer implementation in T2K and a lot of workarounds have been created to overcome these over the years. We did make changes to the XPointer functionality to bring it inline with the standard in the early Witango 5.0 betas but had to quickly roll back the changes as it broke most of the T2K applications that had been built and we took a lot of complaints from the beta testers. The XPointer implementation in T2K was written in the early days of the standard being formulated while XPointer was a moving target which is why it has a lot of quirks. The XPointer parsing routine they wrote uses ID as a special case (which it seemed to be back then in 1998) for use with the function id() which only references the ID attribute and is not sophisticated enough to be able to distinguish between the element ID, attribute ID. With Witango 5.5 we made the decision that the XPointer functionality would not change its behaviour (based on our previous experience) so that we did not break existing applications. XPointer is now of lesser importance in the XML world due to XPath's wider acceptance and we will be focusing on the XPath standard in future Witango releases so you should not expect to see changes to the XPointer functionality in the future. From a technical point of view I would recommend learning XPath and using it in future projects as it is a lot more powerful than XPointer and once you know the syntax it is easier to manipulate a DOM with it. As an aside retrieving the ID element with XPath in Witango 5.5 does work - XPATH="/root/ID" . Phil > From: John McGowan <[EMAIL PROTECTED]> > Date: 28 October 2004 2:00:11 AM > To: [EMAIL PROTECTED] > Subject: Re: Witango-Talk: Old Witango XML Bug > Reply-To: [EMAIL PROTECTED] > > Because the code I'm writing has to run on 5 now and on 5.5 later. > Having it fixed in 5.5 wouldn't have changed my approach that much, > because it still wouldn't work now. I'm just diappointed that the new > server doesn't have better support. I thought that all the XML stuff > was redone. But the fact that this bug still exists tells me that the > @DOM related tags are running the same code they used to. I thought > they were going to us an external library like xerces for XML parsing > and that would apply to xpointer as well. > > I guess not.... > > It's okay.. I worked around it for now. > > I could swear that when we ran into this bug a long time ago we raised > an issue with pervasive or with at the time. (this was a long time ago > that we first discovered the bug, it affects attributes named "id" as > well as elements. > > /John > >> Ben Johansen wrote: >> >> Well if you are going to 5.5 why not just go with XPATH ;-) and drop >> XPOINTER >> >> Ben Johansen - http://www.pcforge.com >> Authorized Witango & MDaemon Reseller Available for Witango >> Developement >> >>> -----Original Message----- >>> From: John McGowan [mailto:[EMAIL PROTECTED] Sent: Wednesday, >>> October 27, 2004 8:12 AM >>> To: [EMAIL PROTECTED] >>> Subject: Re: Witango-Talk: Old Witango XML Bug >>> >>> Thank you Mike... That's not what I was hoping for... >>> >>> /John >>> >>> Mike Scally wrote: >>> >>> >>> Hi John, >>> >>> We are running Witango 5.5.003 Liquorice (Win32) and I get the same >>> results. >>> >>> id= othertag=Y >>> >>> Mike. >>> >>>> -----Original Message----- >>>> From: John McGowan [mailto:[EMAIL PROTECTED] Sent: 27 October 2004 >>>> 15:39 >>>> To: [EMAIL PROTECTED] >>>> Subject: Witango-Talk: Old Witango XML Bug >>>> >>>> Could someone on this side of the globe help me out with something. >>>> >>>> There is a bug that exists up to Witango 5.0. For some reason the >>>> DOM parser can't seem to find elements named "id" >>>> >>>> For example, the following code >>>> >>>> <@assign Name="domvar" Scope="Local" >>>> Value=<@Dom Value="<root><id>X</id><othertag>Y</othertag></root>"> >>>> >>>> >>>> id=<@ELEMENTVALUE >>>> OBJECT="domvar" >>>> SCOPE="Local" >>>> ELEMENT="root().child(1,id)"> >>>> <br> >>>> othertag=<@ELEMENTVALUE >>>> OBJECT="domvar" >>>> SCOPE="Local" >>>> ELEMENT="root().child(1,othertag)"> >>>> >>>> returns >>>> id= >>>> othertag=Y >>>> >>>> when it should return >>>> id= X >>>> othertag=Y >>>> >>>> If someone has a 5.5 server could they please run the test taf >>>> attached to this message just so I can know if the problem is fixed >>>> in 5.5. >>>> >>>> Thanks, >>>> John ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
