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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-query message

[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