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
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
