[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xindice-dev
Subject:    Re: XPath Query attribute/text/comment/etc results
From:       Vadim Gritsenko <vadim () reverycodes ! com>
Date:       2004-02-25 11:39:30
Message-ID: 403C8972.1030107 () reverycodes ! com
[Download RAW message or body]

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
>
>

[prev in list] [next in list] [prev in thread] [next in thread]