Crimson looks like it's been killed. Xerces is a parser. Xalan is a transformation engine.
----- Original Message ----- From: Barney Boisvert <[EMAIL PROTECTED]> Date: Wednesday, March 12, 2003 2:41 pm Subject: RE: XPath in CFMX > I'd use one of the packages from Apache, depending on your > specific need(s) > > http://xml.apache.org > > Xerces and Xalan are the major ones of interest, and Crimson might > be worth > a look. I've not heard much about Crimson, so I don't know if > it's a newly > aquired project, or just always been overshadowed by Xerces. > > > -----Original Message----- > > From: Alexander Sherwood [mailto:[EMAIL PROTECTED] > > Sent: Wednesday, March 12, 2003 1:04 PM > > To: CF-Talk > > Subject: RE: XPath in CFMX > > > > > > At 02:43 PM 3/12/2003 -0600, you wrote: > > > > >Yeah, we've already considered option 1, and we may in fact do > that. We > > >also may end up re-designing our XML structure at some point > > down the road, > > >which could obviate the need for this particular Xpath call. > But, those > > >points aside, it's still mucho annoying that this doesn't work. > > > > Can anyone recommend a good alternative parser to use on Win2K/CFMX? > > > > Thanks! > > > > > > >-----Original Message----- > > >From: Dan G. Switzer, II [mailto:[EMAIL PROTECTED] > > >Sent: Wednesday, March 12, 2003 2:45 PM > > >To: CF-Talk > > >Subject: RE: XPath in CFMX > > > > > > > > >Oh yeah, to workaround the bug, you could write a UDF that you'd > > run before > > >passing the xmlSearch() function that would format it via an > > XPath statement > > >CF likes: > > > > > >So, you'd look for strings ending in: > > >/@attName > > > > > >and replace with > > >[EMAIL PROTECTED] > > > > > >You might also just consider writing your own "xpath()" function > > to use to > > >replace the xmlSearch() function. You could then either choose > to use a > > >Java-based parser, or just reformat strings to make them CFMX > "friendly."> > > > >-Dan > > > > > > > -----Original Message----- > > > > From: Dan G. Switzer, II [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, March 12, 2003 3:34 PM > > > > To: CF-Talk > > > > Subject: RE: XPath in CFMX > > > > > > > > Seems like it is a bug. In following example, the first XPath > > statement > > > > works as expected, the second finds 2 matches, but returns > > empty arrays. > > > > > > > > <cfxml variable="sampleXML"> > > > > <rules> > > > > <rule name="firstRule"> > > > > <subelement name="myAttribute">text here</subelement> > > > > </rule> > > > > <rule> > > > > <subelement name="myAttribute">text here</subelement> > > > > </rule> > > > > <rule name="thirdRule"> > > > > <subelement name="myAttribute">text here</subelement> > > > > </rule> > > > > </rules> > > > > </cfxml> > > > > > > > > <!--// works //--> > > > > <cfset res1 = xmlSearch(sampleXML,"//[EMAIL PROTECTED]")> > > > > <cfdump var="#res1#"> > > > > > > > > <!--// doesn't work //--> > > > > <cfset res2 = xmlSearch(sampleXML,"//rule/@name")> > > > > <cfdump var="#res2#"> > > > > > > > > I also know that the XPath expression "rule/@name" works > with the XSLT > > > > engine--I use that syntax a lot in my XSL sheets. I think > > xmlSearch class > > > > is > > > > probably the culprit. > > > > > > > > -Dan > > > > > > > > > -----Original Message----- > > > > > From: Mueller, Ben [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, March 12, 2003 2:55 PM > > > > > To: CF-Talk > > > > > Subject: RE: XPath in CFMX > > > > > > > > > > The problem is not that MACR returns an array rather than a > > string in > > > > this > > > > > particular XPath case. The problem is that, in the case > where I'm > > > > trying > > > > > to > > > > > get the value of an attribute, it returns an array of > > length one that > > > > > appears to have nothing in it. > > > > > > > > > > If you run this code in MX: > > > > > > > > > > <cfxml variable="sampleXML"> > > > > > <rule name="firstRule"> > > > > > <subelement name="myAttribute">text here</subelement> > > > > > </rule> > > > > > </cfxml> > > > > > > > > > > <cfset res1 = xmlSearch(sampleXML,"rule/@name")> > > > > > <cfdump var=#res1#> > > > > > > > > > > ...you'll see that the cfdump of the "res1" object has no > > data in it. > > > > If > > > > > it > > > > > returned the value of the attribute somewhere in the array, > > I'd be home > > > > > free. > > > > > > > > > > Is there something really basic about this that I'm missing? > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Alexander Sherwood [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, March 12, 2003 1:47 PM > > > > > To: CF-Talk > > > > > Subject: RE: XPath in CFMX > > > > > > > > > > > > > > > At 11:19 AM 3/12/2003 -0600, you wrote: > > > > > > > > > > >That's sort of what I was afraid of. If it's legal XPath > > syntax, then > > > > > why > > > > > >doesn't the XmlSearch function support it? Is it a > > weakness in MX, or > > > > is > > > > > >this a deliberate omission? And does anybody know if MM > > has plans to > > > > > >support this in the future? > > > > > > > > > > Well, i think it has more to do with how MACR wanted to > > implement the > > > > > XMLSearch feature. The W3C spec doesn't specifiy how the > > parser should > > > > > return data, it just specifies that the XPATH should > locate the > > > > > element/attribute in the document - no matter what. > > > > > > > > > > MACR just decided that they wanted to return an array > > instead of say, a > > > > > string variable or a number. This makes sense when, in > many cases, > > > > you're > > > > > not sure how much data is going to come back. The function is > > > > standardized > > > > > to return the same data type on each call: an array. > > > > > > > > > > Look at this Xpath, for example: '//Address'. If you > > XMLSearch()'ed on > > > > > this > > > > > path and the parser found 4 valid elements, how would it be > > returned to > > > > > you? In an array or some other "collection" like data type > > (struct, hash > > > > > table, etc.). > > > > > > > > > > BUT, when you are using XMLSearch() to grab one element's > > attribute, how > > > > > can the function just return you a string, and not an > > array? You would > > > > > have > > > > > to write code after each function call to decided how to > process the > > > > > return > > > > > data. Did I get back an array to loop over or a string? > > MACR just went > > > > > with > > > > > the array because it make the most sense - regardless of > > what the parser > > > > > finds. Even if you search for one element, you grab it at > > index[1], and > > > > > use > > > > > XMLAttributes to extract the string or numeric value. > > > > > > > > > > It would be nice, however, to have an XMLExtractAttribute() > > function, > > > > that > > > > > simply returns the first attribute (in the form of a string > > return type) > > > > > value found for the supplied XPATH. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >-----Original Message----- > > > > > >From: Jochem van Dieten [mailto:[EMAIL PROTECTED] > > > > > >Sent: Wednesday, March 12, 2003 11:24 AM > > > > > >To: CF-Talk > > > > > >Subject: Re: XPath in CFMX > > > > > > > > > > > > > > > > > >Mueller, Ben wrote: > > > > > > > Yes, that is exactly what I want. It would appear (at > > least from > > > > > > > Microsoft's website) that this is legal Xpath syntax. > > A previous > > > > > poster > > > > > > > suggested that this may have been an extension MS made > > that falls > > > > > outside > > > > > > > the w3c spec. At this point, I'd be happy with > > confirmation that a > > > > > call > > > > > > > like "Books/Book/@type" is just illegal according to > > the w3c spec. > > > > > > > > > > > >I think it is legal syntax. http://www.w3.org/TR/xpath > section 2.5 > > > > > > > > > > > >Jochem > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4 FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
