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

 


Help: OASIS Mailing Lists Help | MarkMail Help

oslc-core message

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