OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [security-services] Groups - XPath Attribute Profile (draft-saml2-xpath-attribute-profile.sxw) uploaded

IETF is working on something called xCap which might be relevant to the 
discussion here.
The goal is to retrieve attributes from XML documents (buddy lists in a 
SIP context).
See http://www.jdrosen.net/simple_acap.html
They define a very restricted subset of XPath.

I am not sure what follows is something that you guys need, but the 
email asked for "ideas".

I have been working on a new language -- called XSquirrel -- that 
addresses some of these issues.
I don't want to retrieve just the attributes, but rather the 
sub-document that contains the attributes.
For instance /root/body/thing[1] would return


The reason for this "sub-document" semantics is that a query consumes a 
document to produce a document (XPath consumes a document to produce a 
nodeset). Therefore queries can be composed.
Having the document structure is also very important when doing merging 
of data coming from multiple repositories or data synchronization.

In case you are interested, check 
There is also an upcoming research paper to be presented at WWW 2005 in May.


Arnaud Sahuguet

Cameron Morris wrote:

> >I would be very interested in ideas people have for defining a subset of
> >XPath that can be used for uniquely identifying Attributes within an XML
> >document, even if that subset restricts the ability to identify
> >Attributes based on query functions.
> Good point.  The Liberty data template specification lets each service 
> define whether or not to support full xpath or not.  If full xpath is 
> not supported, the supported xpath identifiers for each attribute are 
> enumerated by the service definition.
> A restricted XPath used only for identifying nodes I think is 
> certainly possible.  It would only include the xml document structure 
> with probably the positional expressions: no wild-cards, 
> descendant-of, ancestor-of, or other functions.
> Also I think full XPath could be used in an attribute query, where the 
> restricted xpath would apply to attribute statements and metadata. 
>  Would it seem weird that one attribute name in a query could result 
> in multiple attributes returned?
> Here are some exploratory examples:
> Suppose some document looks like this:
> <root>
>    <body>
>       <thing>thing1</thing>
>       <thing>thing2</thing>
>    </body>
> </root>
> An attribute query with an xpath attribute name of 
> "/root/body/thing[2]" could result in the following:
> <saml:Attribute name="uri:xpath:/root/body/thing[2]">
>    <value>thing2</value>
> </saml:Attribute>
> "uri:xpath:/root/body" results:
> <saml:Attribute name="uri:xpath:/root/body">
>    <value>
>       <thing>thing1</thing>
>       <thing>thing2</thing>
>    </value>
> </saml:Attribute>
> "uri:xpath:/root/body/thing" results:
> <saml:Attribute name="uri:xpath:/root/body/thing[1]">
>    <value>thing1</value>
> </saml:attribute>
> <saml:Attribute name="uri:xpath:/root/body/thing[2]">
>    <value>thing2</value>
> </saml:attribute>
> - Cameron

fn:Arnaud Sahuguet
org:Bell Labs Research;Network Data and Services
adr:;;600 Mountain Ave;Murray Hill;NJ;07974;USA
tel;work:+1 908 582 6491
note;quoted-printable:Blog: http://sahuguet.blogspot.com/=0D=0A=
	Web: http://db.bell-labs.com/user/sahuguet/

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]