You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xindice-dev@xml.apache.org by Vadim Gritsenko <va...@reverycodes.com> on 2004/02/25 04:45:10 UTC

XPath Query attribute/text/comment/etc results

Hi all,

Is there any opinion on how results of the XPath query returning 
attribute(s), text node(s), comment node(s), etc should look like? Up to 
the couple of days ago, it would just add those to the resulting 
document, and pass those DOM nodes as is. This causes issues:

  * With XML-RPC (can't build resulting document - can't have 2 
attributes; merges text nodes; etc)
  * With source meta data attributes (can't attach meta data attributes 
to attributes / text / etc)


Solution to this problem is to create result element in query namespace 
(<query:result>) to hold these result nodes. This solves both issues 
above. The only question left which I have is what should XMLResource on 
the client side return on getContent() and getContentAsDOM(). There are 
two options:

  (a) Return <query:result> element containing result node (attribute / 
text / etc), as well as source meta attributes.
  (b) Return result node alone. User would have to use 
getContentAsDOM().getOwnerDocument() to get hold of source meta 
attributes, and via getContent() those meta attributes would not be 
available at all. It also looses name of the result attribute (passes 
only value).

Any opinions? I'm think first option is better.

Vadim


Re: XPath Query attribute/text/comment/etc results

Posted by Terry Rosenbaum <Te...@amicas.com>.
+1 for (a). Like to see the attributes named.

-Terry

Vadim Gritsenko wrote:

> Hi all,
>
> Is there any opinion on how results of the XPath query returning 
> attribute(s), text node(s), comment node(s), etc should look like? Up 
> to the couple of days ago, it would just add those to the resulting 
> document, and pass those DOM nodes as is. This causes issues:
>
>  * With XML-RPC (can't build resulting document - can't have 2 
> attributes; merges text nodes; etc)
>  * With source meta data attributes (can't attach meta data attributes 
> to attributes / text / etc)
>
>
> Solution to this problem is to create result element in query 
> namespace (<query:result>) to hold these result nodes. This solves 
> both issues above. The only question left which I have is what should 
> XMLResource on the client side return on getContent() and 
> getContentAsDOM(). There are two options:
>
>  (a) Return <query:result> element containing result node (attribute / 
> text / etc), as well as source meta attributes.
>  (b) Return result node alone. User would have to use 
> getContentAsDOM().getOwnerDocument() to get hold of source meta 
> attributes, and via getContent() those meta attributes would not be 
> available at all. It also looses name of the result attribute (passes 
> only value).
>
> Any opinions? I'm think first option is better.
>
> Vadim
>

Re: XPath Query attribute/text/comment/etc results

Posted by Vadim Gritsenko <va...@reverycodes.com>.
Ryan Hoegg wrote:

> I like (a) as well.  However, I think this is a wart in the XMLDB 
> spec.  I think these return types don't really belong in a DOM.  I 
> briefly looked at xmldb.org, and the spec and use cases didn't seem to 
> address the case where an xpath query returns something that doesn't 
> lend itself to DOM representation.  If I am simply trying to retrieve 
> a set of attribute values, it seems to me I should end up with a 
> Collection of Strings...


But String does not make good XMLResource...


> how will this look using a <query:result/> element?  For example:
>
> I have a collection at /db/teams that contains 29 documents.  Each 
> document's root element is named "team".  That element contains some 
> number of "player" elements, each with an attribute named 
> "jersey-number".  Each player also contains a "name" element which in 
> turn contains an element named "last" that contains only text 
> content.  If I query for 
> /db/teams/team/player[@jersey-number=4]/name/last/text() what will I 
> end up with?


Each result will be:
    <ns:result xmlns:ns="http://xml.apache.org/xindice/Query" 
ns:col="/db/teams" ns:key="12">Ryan</ns:result>

Vadim


> -- 
> Ryan Hoegg
> ISIS Networks
> http://www.isisnetworks.net/
>
> Vadim Gritsenko wrote:
>
>> Hi all,
>>
>> Is there any opinion on how results of the XPath query returning 
>> attribute(s), text node(s), comment node(s), etc should look like? Up 
>> to the couple of days ago, it would just add those to the resulting 
>> document, and pass those DOM nodes as is. This causes issues:
>>
>>  * With XML-RPC (can't build resulting document - can't have 2 
>> attributes; merges text nodes; etc)
>>  * With source meta data attributes (can't attach meta data 
>> attributes to attributes / text / etc)
>>
>>
>> Solution to this problem is to create result element in query 
>> namespace (<query:result>) to hold these result nodes. This solves 
>> both issues above. The only question left which I have is what should 
>> XMLResource on the client side return on getContent() and 
>> getContentAsDOM(). There are two options:
>>
>>  (a) Return <query:result> element containing result node (attribute 
>> / text / etc), as well as source meta attributes.
>>  (b) Return result node alone. User would have to use 
>> getContentAsDOM().getOwnerDocument() to get hold of source meta 
>> attributes, and via getContent() those meta attributes would not be 
>> available at all. It also looses name of the result attribute (passes 
>> only value).
>>
>> Any opinions? I'm think first option is better.
>>
>> Vadim
>
>


Re: XPath Query attribute/text/comment/etc results

Posted by Ryan Hoegg <rh...@isisnetworks.net>.
I like (a) as well.  However, I think this is a wart in the XMLDB spec.  
I think these return types don't really belong in a DOM.  I briefly 
looked at xmldb.org, and the spec and use cases didn't seem to address 
the case where an xpath query returns something that doesn't lend itself 
to DOM representation.  If I am simply trying to retrieve a set of 
attribute values, it seems to me I should end up with a Collection of 
Strings... how will this look using a <query:result/> element?  For example:

I have a collection at /db/teams that contains 29 documents.  Each 
document's root element is named "team".  That element contains some 
number of "player" elements, each with an attribute named 
"jersey-number".  Each player also contains a "name" element which in 
turn contains an element named "last" that contains only text content.  
If I query for /db/teams/team/player[@jersey-number=4]/name/last/text() 
what will I end up with?

--
Ryan Hoegg
ISIS Networks
http://www.isisnetworks.net/

Vadim Gritsenko wrote:

> Hi all,
>
> Is there any opinion on how results of the XPath query returning 
> attribute(s), text node(s), comment node(s), etc should look like? Up 
> to the couple of days ago, it would just add those to the resulting 
> document, and pass those DOM nodes as is. This causes issues:
>
>  * With XML-RPC (can't build resulting document - can't have 2 
> attributes; merges text nodes; etc)
>  * With source meta data attributes (can't attach meta data attributes 
> to attributes / text / etc)
>
>
> Solution to this problem is to create result element in query 
> namespace (<query:result>) to hold these result nodes. This solves 
> both issues above. The only question left which I have is what should 
> XMLResource on the client side return on getContent() and 
> getContentAsDOM(). There are two options:
>
>  (a) Return <query:result> element containing result node (attribute / 
> text / etc), as well as source meta attributes.
>  (b) Return result node alone. User would have to use 
> getContentAsDOM().getOwnerDocument() to get hold of source meta 
> attributes, and via getContent() those meta attributes would not be 
> available at all. It also looses name of the result attribute (passes 
> only value).
>
> Any opinions? I'm think first option is better.
>
> Vadim
>