[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] (OSLCCORE-138) OSLC Query BNF for wildcards seems questionable
[ https://issues.oasis-open.org/browse/OSLCCORE-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=68067#comment-68067 ] Andrii Berezovskyi commented on OSLCCORE-138: --------------------------------------------- Thanks David, by "we" here I was speaking as a Core TC member, not as a Lyo lead :) In Lyo we indeed use ANTLR grammar, but it was created by hand and resembles the BNF in the spec rather loosely: oslc_where : compound_term ; compound_term : simple_term ( boolean_op simple_term)* -> ^( 'terms' simple_term (simple_term)* ) ; simple_term : term | scoped_term ; space : ' '! ; boolean_op : ' and '! ; term : term_simple | in_term ; term_simple : identifier_wc comparison_op value -> ^( 'simple_term' identifier_wc comparison_op value ) ; in_term : identifier_wc in_op space? in_val -> ^( 'in_term' identifier_wc in_val ) ; scoped_term : identifier_wc '{' compound_term '}' -> ^( 'compound_term' identifier_wc compound_term ) ; identifier_wc : identifier | wildcard ; identifier : prefixedName ; wildcard : ASTERISK ; comparison_op : '=' | '!=' | '<' | '>' | '<=' | '>=' ; in_op : ' in' ; in_val : '[' value (',' value)* ']' -> ^( 'in_values' value (value)* ) ; value : iriRef | literal_value ; literal_value : boolean_val | decimal | string_esc | typed_string | langed_string ; typed_string : string_esc ( '^^' prefixedName ) -> ^( 'typed_value' string_esc prefixedName? ) ; langed_string : string_esc LANGTAG -> ^( 'langed_value' string_esc LANGTAG ) ; boolean_val : BOOLEAN ; decimal : DECIMAL ; string_esc : STRING_LITERAL ; properties : property (',' property )* ; property : prefixedName ( nested_property )* ; nested_property : '{' property (',' property )* '}' ; iriRef : IRI_REF | prefixedName ; prefixedName : PNAME_LN | PNAME_NS ; *** On the MAY implementation of the wildcard, I agree that we can make it if there are no major OSLC 2 query implementation that allow queries like * { foaf:name = "username" } . Regarding SPARQL operator compabiity, I, unfortunatly, agree with the original spec that mandates the equivance. The reason is simple: it has rather simple semantics defined in XML Query terms and are not that hard to implement. Also, OSLC was supposed to provide a sane way for enterprises to move towards RDF and, hence, RDF stores (all of which support SPARQL nowadays). My suggestions: * publish OSLC Query BNF as the stripped-down ANTLR source (which uses EBNF), so that we can check it in Antlr IDE * make wildcard property handling a MAY > OSLC Query BNF for wildcards seems questionable > ----------------------------------------------- > > Key: OSLCCORE-138 > URL: https://issues.oasis-open.org/browse/OSLCCORE-138 > Project: OASIS OSLC Lifecycle Integration Core (OSLC Core) TC > Issue Type: Bug > Components: Query > Reporter: Andrii Berezovskyi > Assignee: James Amsden > > I was about to answer this question https://jazz.net/forum/questions/227587/how-to-use-rm-apioslc-where-clause-using-not-equal-null-conditions with the link to the OSLC Query spec but then I saw !="*" on the linked docs in https://www.ibm.com/support/knowledgecenter/SSZRHJ/com.ibm.mif.doc/gp_intfrmwk/oslc/r_oslc_query_params.html. > That made me read BNF extra carefully and from the shortened subset below you can see my concern: > oslc_where ::= "oslc.where=" compound_term > compound_term ::= simple_term (space? boolean_op space? simple_term)* > simple_term ::= term | scoped_term > space ::= " " /* a space character */ > boolean_op ::= "and" > term ::= identifier_wc comparison_op value | identifier_wc space in_op space? in_val > scoped_term ::= identifier_wc "{" compound_term "}" > identifier_wc ::= identifier | wildcard > This query is valid: > oslc.where=* > 10 > While this one is invalid: > oslc.where=name=* > Now that I look at my examples, this actually makes sense (leaving aside a question why would you filter by any property being greater than a certain number), while IBM manual's "The parent!="*" query is semantically equivalent to the parent="NULL" query." does not! > Do you have any automatic BNF validators to check the sanity of the BNF further? -- This message was sent by Atlassian JIRA (v6.2.2#6258)
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]