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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-regrep message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: RE: Updated Constrained OQL proposal


<fn>
Short answer I forgot to mention is that no there is no such explicit
requirement that the query syntax be mappable to SQL. However I do see the
following requirements:

1. Easy to use and familiar syntax for clients
2. Based on a standard
3. Able to make use of RIM attributes and methods to perform the kind of
queries exemplified in:

http://lists.ebxml.org/archives/ebxml-regrep/200101/msg00098.html
</fn>

I would argue that an XML-specific query language such as XPath would
satisfy 1 & 2, and 3 could be met easily by
allowing AND & OR to be used to concatenate XPath statements, e.g.

/granddad/dad[1]/kid[@name = "tim"] AND /granddad/dad[2]/kid[@name = "bob"]

There are freely available XPath implementations that people could use to
achieve the above.  I feel the above is a better solution than using
OQL/SQL, but I stil don't like it because it explicity defines the actual
query mechanism.  I would rather see an interface which allows the
implementer to select what query/storage mechanism is used.  The obvious
solution to me is to forget this notion of "adhoc queries", and instead
implement more methods on the registry.  Currently, there are a bunch of
get*() methods defined, how about defining a bunch of find*() methods, and
skirt the QL issue like they have done in UDDI.  I know that if OQL/SQL is
used today, we will regret it tomorrow - especically when XML Query produces
something.


<fn>
Just curious. How does XML Global store metadata for their registry?
</fn>

Can't you guess?  We have our own native XML database that uses QUILT as its
QL.  This really is immaterial, however - we could easily support OQL if we
had to, it is just wrong in my mind, as the metadata is defined in XML.

The find*() approach will certainly scratch your OO itch, so what is the
problem with that idea?

:-P

Cheers,

Matt



BTW Sorry about mis-spelling your name.

Matthew MacKenzie wrote:

> Farrukh,
>
> Is "mapping to SQL" a requirement of regrep adhoc query?  Your proposal
> stinks of technology bias, and I hope the group recognizes that.
>
> --
> Matthew MacKenzie
> VP Research & Development
> XML Global Technologies, Inc.
>
> -----Original Message-----
> From: Farrukh Najmi [mailto:Farrukh.Najmi@east.sun.com]
> Sent: January 11, 2001 6:15 AM
> To: ebxml-regrep@lists.ebxml.org
> Subject: Updated Constrained OQL proposal
>
> Attached is an update to the previous document on my brain dump on ad
> hoc queries.
>
> The changes are:
>
> -Much more examples on the types of queries IMHO need to be supported
> -Now uses attribute names rather than accessor method names wherever
> possible
> -Added section on mapping OQL to SQL
>
> I look forward to your comments.
>
> --
> Regards,
> Farrukh

--
Regards,
Farrukh

BEGIN:VCARD
VERSION:2.1
N:MacKenzie;Matthew
FN:Matthew MacKenzie
NICKNAME:Matt
ORG:XML Global Technologies, Inc.;Research & Development
TITLE:VP Research & Development
TEL;WORK;VOICE:(604) 717-1100
TEL;VOICE:(800) 201-1848
TEL;WORK;FAX:(604) 717-1107
ADR;WORK;ENCODING=QUOTED-PRINTABLE:;;1818 Cornwall Avenue=0D=0ASuite 9;Vancouver;British Columbia;V6J 1C7;Canad=
a
LABEL;WORK;ENCODING=QUOTED-PRINTABLE:1818 Cornwall Avenue=0D=0ASuite 9=0D=0AVancouver, British Columbia V6J 1C7=
=0D=0ACanada
URL:
URL:http://www.xmlglobal.com
EMAIL;PREF;INTERNET:matt@xmlglobal.com
EMAIL;INTERNET:matt@GoXML.com
REV:20001228T191617Z
END:VCARD


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help


Powered by eList eXpress LLC