Unable to extract Attribute Value w/ Path

[jranson]

Consider the following document partial (source: https://community.cablelabs.com/wiki/plugins/servlet/cablelabs/alfresco/download?id=8f900e8b-d1eb-4834-bd26-f04bd623c3d2 , Appendix I.1)

<?xml version="1.0" ?>
<ADI>
  <Metadata>
    <AMS Provider="InDemand" Product="First-Run" Asset_Name="The_Titanic" Version_Major="1" Version_Minor="0" Description="The Titanic asset package" Creation_Date="2002-01-11" Provider_ID="indemand.com" Asset_ID="UNVA2001081701004000" Asset_Class="package"/>
    <App_Data App="MOD" Name="Provider_Content_Tier" Value="InDemand1" />
    <App_Data App="MOD" Name="Metadata_Spec_Version" Value="CableLabsVod1.1" />
  </Metadata>
</ADI>

While i can use a Path like //AMS[@Asset_Class='package']/../App_Data[@Name='Provider_Content_Tier'] to get to a desired Element, I am not able to perform an xpath-style path search to extract just the data in the Value attribute for the identified elements as a []string. Most other XPath implementations support a path such as //AMS[@Asset_Class='package']/../App_Data[@Name='Provider_Content_Tier']/@Value to extract attribute values directly from the Path.

This would be a really great feature to have to allow us to port a legacy app over to Go, without having to refactor our existing paths that perform the attribute extractions.

I'll take a stab at implementing in the coming days.

[beevik]

One thing to keep in mind is that, unlike XPath, the etree Path library returns Element pointers instead of strings. This might make it tricky to support XPath-like queries that return attributes, since Attributes are a whole separate type in etree.

[jranson]

Yeah, my initial thinking was providing a new function like GetAttribute() that accepts the Path and returns []string. Do you have any thoughts on that? Thanks for getting back to me!

[beevik]

Without having given this a whole lot of thought, my first inclination would be to add FindAttribute and FindAttributes methods that return Attr pointers. This would keep them similar to FindElement and FindElements. But I'm not sure that would be very useful, since the Attr instances do not maintain any information about the element they belong to (unlike the Element instances, which know their children and parents).

What you're asking for is basically a new kind of path system that works more like XPath and less like etree Paths. Basically, you're looking for something that returns strings. Normally when people ask for this, I refer them to the xmlpath package. etree has never attempted to provide a compliant XPath implementation. The path system used by etree is more similar to the python etree module upon which I modeled it.

[beevik]

Oh, one other thing. I'm going to be replacing the current etree path implementation with the code in pull request #50. I still need to optimize it, so I'm not ready to commit it yet. But if you're going to do any work on paths, you'd probably want to start there.

[beevik]

Closing this issue since there has been no update for several months. Feel free to reopen if you decide to further pursue this.