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: lates RR specs


Message text written by Farrukh Najmi
>Then there is the issue of the ability to do the kind of queries we need
in
either syntax. I believe that OQL can meet all our needs for the most
complex
queries (Classification Queries) with relative ease. I do not even know
whether
XPATH could do the same. I have asked Eve Maler from Sun who is one of the
principal authors behind XPATH to attend the meeting at 10 am today so she
can
help us figure out how XPATH could work. I have also invited Mike Rowley
from
Excelon Corp to attend for the same reason.

Finally there is a small issue that we will need to eventually support
content
based predicates in ad hoc queries and not all Registry content will be
XML.

I think a main issue for OQL is one of fear of the perceived complexity of
OQL.
To that end I am working within Sun to get permission to make our query
processor engine for RR OQL be made publicly available in source code form
to
anyone. This should help allay the fear of OQL.

As far as XPATH goes, I believe the choice would be much less controversial
but
as I said, I am not sure whether it would be the right choice.
<<<<<<<<<<<<

Farrukh,

I would agree with JP here.  Let's walk with XPath style approach first,
and then 
decide if we need to run with OQL or similar as Registry implementations
mature.

Of course XMLG is the vendor that is using pure XML backend storage
techniques
for Registry implementation - but others such as Excelon will do like wise.

Longer term - getting out the crystal ball - all backend storage systems -
Oracle,
et al will be full XML based - so this just makes good sense.

While we appreciate the offer of OQL parser - that's not really the issue. 
Much
more important is the implementation mechanics on the backend - and that
is a significant hurdle for implementors.   We really want to promote a
model
where people can build Registry implementations lightweight and
uncomplicated.

It's quite one thing to postulate that complex  querying is required, and
quite 
another to actually find killer business needs.  I would suggest that for
most
early registry work right now XPath will be more than adequate.  Also XPath
has the secondary benefit of being able to be emitted from a XML parser,
something that OQL certainly cannot.

Thinking simple can sometimes be tough.

Thanks, DW.



[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