[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: BNF for SQL LIKE Predicate
Len, Most SQL implementations I have used support '%' and '*' interchangeably and '?' and '_' interchangeably. What do you suggest on the delimeter issue? We could clarify that the single quote character must be specified as String delimeter. Len Gallagher wrote: > Farrukh, > > Unfortunately, the text I wrote is not complete, so it is not a proposal. > Although it could become the basis of a proposal. Here are some unaddressed > issues: > > 1) The SQL standard requires a single quote character as a character string > delimiter, while XML in general is expecting a double quote. If we embed > SQL syntax into our XML element for "Clause", how does this difference get > resolved? > > 2) SQL specifies the percent character (%) as its "arbitrary string > specifier" and the underscore character (_) as its "arbitrary character > specifier". This is different than the "%" or "*" and "?" suggested in your > earlier comments. Is that OK with existing implementations of LIKE-like > functionality? > > -- Len > > At 11:54 AM 9/24/01, Farrukh Najmi wrote: > >Len, > > > >I agree with your proposed text. I feel it should be placed in the appendix of > >RS and referenced from main text. > > > >BTW we know of at least one XML Vendor XML Global that feels quite comfortable > >with this idea. See: > > > >http://lists.oasis-open.org/archives/regrep-query/200109/msg00003.html > >(Matt's agreement) > >http://lists.oasis-open.org/archives/regrep-query/200109/msg00001.html > >(David's agreement) > > > > > > > >Len Gallagher wrote: > > > > > Query team, > > > > > > During last Friday's teleconference I expressed some concern about ad hoc > > > adoption of SQL LIKE predicate syntax in our "Clause" element for Registry > > > Query. The reason for my reluctance is the complexity of SQL LIKE. I'm > > > convinced that XML vendors will not be willing to implement it > > > completely. The trick is then to agree on some reasonable subset. > > > > > > Attached is a file called "LIKEpredicate.txt" that is copied from the BNF > > > for the SQL <like predicate> as specified in ISO/IEC 9075-2:1999. It is > > > very complex because it takes full advantage of the power of SQL and allows > > > character expressions, character functions, and numeric functions in its > > > specification. > > > > > > If we decide to go this route -- and I'm still not convinced that a > > > majority of the vendors (or Registry clients) will want to do that -- then > > > we need to agree on some restrictions. Here are some suggestions: > > > > > > 1) The SQL LIKE predicate for Registry Query shall be a <character like > > > predicate>. > > > > > > 2) The <character match value> in a <character like predicate> shall be a > > > <column reference> that is a single <column name> that matches a visible > > > attribute name of the relevant Registry Query class. The underlying data > > > type of this attribute shall be "String". > > > > > > 3) The <character pattern> in a <character like predicate> shall be a > > > <character string literal> that does not contain a <character set > > > specification> or a <character representation>. > > > > > > 4) The <escape character> in a <character like predicate> shall be a > > > <character string literal> that does not contain a <character set > > > specification> or a <character representation>. > > > > > > With these restrictions, the SQL LIKE predicate for Registry Query could be > > > reduced to the following BNF representation: > > > > > > <character like predicate> ::= > > > <column name> [ NOT ] LIKE <character pattern> > > > [ ESCAPE <escape character> ] > > > > > > <character pattern> ::= <character string literal> > > > > > > <escape character> ::= <character string literal> > > > > > > <character string literal> ::= <quote> [ <character representation>... ] > > > <quote> > > > > > > <character representation> ::= <nonquote character> | <quote symbol> > > > > > > <nonquote character> ::= -- Any character from the default character set > > > that is not a single quote character, i.e. not the ' character. > > > > > > <quote symbol> ::= <quote><quote> > > > > > > But this still leaves the very comprehensive rules for how to specify and > > > implement the <character pattern> and <escape character> -- but these rules > > > are fully specified in the SQL standard and we could simply point to them. > > > > > > Regards, > > > Len > > > > > > ************************************************************** > > > Len Gallagher LGallagher@nist.gov > > > NIST Work: 301-975-3251 > > > Bldg 820 Room 562 Home: 301-424-1928 > > > Gaithersburg, MD 20899-8970 USA Fax: 301-948-6213 > > > ************************************************************** > > > > > > ------------------------------------------------------------------------ > > > > > > LIKEpredicate.txtName: LIKEpredicate.txt > > > Type: Plain Text (text/plain) > > > >-- > >Regards, > >Farrukh > > > > ************************************************************** > Len Gallagher LGallagher@nist.gov > NIST Work: 301-975-3251 > Bldg 820 Room 562 Home: 301-424-1928 > Gaithersburg, MD 20899-8970 USA Fax: 301-948-6213 > ************************************************************** > > ---------------------------------------------------------------- > To subscribe or unsubscribe from this elist use the subscription > manager: <http://lists.oasis-open.org/ob/adm.pl> -- Regards, Farrukh
begin:vcard n:Najmi;Farrukh tel;work:781-442-0703 x-mozilla-html:FALSE url:www.sun.com org:Sun Microsystems;Java Software adr:;;1 Network Dr. MS BUR02-302;Burlington;MA;01803-0902;USA version:2.1 email;internet:najmi@east.sun.com fn:Farrukh Najmi end:vcard
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC