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] | [Elist Home]


Subject: RE: Issue: Request query language


Thanks for the comments, I've just added a few more of mine with major
snippage.

<xml:delete/>  <!-- new tag created for snipping, the opposite of xinclude
;-) -->

I'm tending to believe that the queries could be quite complicated.  Imagine
that systems are going to want a PDP to express a query that is based upon
an XACML repository.  Perhaps a key question is how are the queries going to
be generated?  If they are generated by particular rules, they don't need to
be human-centric.

I agree with tracking xml based syntaxes.  I am especially interested in the
XQuery element syntax as I'm not a big fan of $.

Though I don't think it should be an explicit design goal.  I'm actually
quite content with using new XML string syntaxes to express the guts.  

<aside>There are many situations where strings are better to express the
query than xml syntax because of compactness and expressiveness.  From a
query engines perspective, there is generally no difference as the query
engine will have to take the string syntax into nodes anyways.  In the same
way that I don't think that <xsl:if test=""><else> is better than if (){}
else{} just because it has pointy-brackets, I don't think <xquery:for
variable="S" href="VirtualAssertionList.xml"> ... <AND> ... is automatically
better than FOR $S IN document("VirtualAssertionList.xml").... AND ...  A
cool thing about query is that it has an algebra than can be expressed in
many syntaxes.  But then I'm one of those kind that still likes DTDs compact
content model compared to schema.</aside>

But expressing boolean operations and lexical constraints in element syntax
leads to re-creating xml schema.  It's pretty clear that a schema can also
be used as a query, which I wanted to avoid.  I guess a 5th option would be
to use a derivative of schema, ie

5)
<requestidentifier>
<element name="SAML">
<complexType>
<all>
<element name="Resource">
<attribute name="string" value="http://store.carol.test/finance">
</element>
<element name="Subject">
<element name="KeyInfo">
<element name="X509Data">
<element name="someinternalelement" value="carol">
</element></element></element></element>

I'm not a fan of this approach, although it does use xml element syntax and
it does re-use schema constructs.  Seems like XPath is easier to express
child relationships using a "/" than nested elements.  

> Both this option and option #4 use a non-XML syntax to 
> express the "guts" 
> of the request, which seems not quite right to me.  XML 
> syntaxes are being 
> proposed for XPath (informally) and for XQuery (formally 
> through W3C), so 
> we should keep an eye on these developments.
> 
> >4)
> ><requestidentifier>
> >FOR $S IN document("VirtualAssertionList.xml")//SAML
> >WHERE $S/Resource/string = "http://store.carol.test/finance"
> >AND $S/Subject/KeyInfo/X509Data/someinternalelement = "carol"
> >RETURN $S
> >
> ><!-- now we're cooking with gas as we can do just about any type of
> >expression possible, and we haven't created a new syntax -->
> >
> >It all depends upon how complex the queries and results will 
> be.  I have a
> >feeling people are wanting complex queries - which leans to 
> more of an
> >XQuery language.  If it turns out that all of our queries 
> are fairly simple,
> >then I'm more comfortable with inventing a simple syntax.
> 
> I'm with you on this.
> 
> >[1]http://www.w3.org/TR/xpath.html
> >[2]http://www.w3.org/TR/xquery/
> 
>          Eve
> --
> Eve Maler                                             +1 781 442 3190
> Sun Microsystems XML Technology Development  eve.maler @ east.sun.com
> 
> 
> ------------------------------------------------------------------
> To unsubscribe from this elist send a message with the single word
> "unsubscribe" in the body to: 
> security-services-request@lists.oasis-open.org
> 

Dave Orchard
XML Architect
Jamcracker Inc.,    19000 Homestead Dr., Cupertino, CA 95014
p: 408.864.5118     m: 604.908.8425    f: 408.725.4310

www.jamcracker.com - Sounds like a job for Jamcracker.


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


Powered by eList eXpress LLC