[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