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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-comment message

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


Subject: Re: [regrep-comment] Comment about ebRIM, section 7.4.2


Hi Farrukh!

Some of the confusion about the current version of section 7.4.2 is caused 
by the usage of "support". Does it mean the ability to store AdhocQuery 
objects or the ability to execute queries of a given query language? Your 
suggested text doesn't remove this ambiguity entirely, also because it 
uses both "support" and "implement". To improve the clarity of the specs, 
I would suggest a more radical solution which is to not at all discuss 
"support" in ebRS and instead add a new section to ebRS discussing how 
additional query languages may be supported (in the sense of able to 
execute).

My suggestion is therefore to retain only the first two sentences in 
section 7.4.2:

"7.4.2 Attribute queryLanguage

The queryLanguage attribute specifies the query language that the query 
expression conforms to. The
value of this attribute MUST be a reference to a ClassificationNode within 
the canonical QueryLanguage
ClassificationScheme."

These two statements should be sufficient because section 1.6 implies that 
the four predefined query languages must be present in the QueryLanguage 
ClassificationScheme and that this ClassificationScheme may be extended 
with additional query languages. At the same time the ambiguity caused by 
the usage of "support" is avoided.

The question about support (in the sense of ability to execute) would then 
be addressed in ebRS. In particular, for additional query languages, I 
suggest to add the following section:

"6.7 Support for additional query syntaxes

An ebXML Registry MAY support additional query syntaxes other than the two 
syntaxes described in this specification. Additional query syntaxes MUST 
be declared as ClassificationNodes within the canonical QueryLanguage 
ClassificationScheme. An ebXML Registry MUST NOT use predefined 
ClassificationNodes within the QueryLanguage ClassificationScheme to 
describe query syntaxes not conforming to ebXML specifications. In 
particular, XPath and XQuery are reserved."

Regards,

Andreas


Farrukh Najmi <farrukh@wellfleetsoftware.com> wrote on 04/10/2007 
19:05:15:

> Hi Andreas,
> 
> Here is the replacement text for ebRIM 3.0.2. Please take a quick look 
> and comment if this is a good fix.
> If not, please suggest alternative text. Thanks.
> 
> 
>       Attribute queryLanguage
> 
> The queryLanguage attribute specifies the query language that the query 
> expression conforms to. The value of this attribute MUST be a reference 
> to a ClassificationNode within the canonical QueryLanguage 
> ClassificationScheme. All query languages supported by a Registry MUST 
> be declared as a ClassificationNode within the canonical QueryLanguage 
> ClassificationScheme. A Registry MAY implement a subset of the query 
> languages defined within the canonical QueryLanguage 
> ClassificationScheme as dictated by the conformance profile implemented 
> by the registry. The canonical QueryLanguage ClassificationScheme MAY 
> easily be extended by adding additional ClassificationNodes to it to 
> allow a registry to support additional query language syntaxes.
> 
> 
> Farrukh Najmi wrote:
> > Hi Andreas,
> >
> > The intent of the specs was to state that:
> >
> >    * Filter queries MUST be supported as described by ebRS
> >    * SQL Queries MAY be supported as described by ebRS
> >    * Any other query syntax MAY be supported as long as it is declared
> >      in the canonical QueryLanguage ClassificationScheme
> >
> >
> > Clearly the spec is not clear in Section 7.4.2 of ebRIM. We will 
> > consider this a minor spec bug and fix it in our next revision.
> >
> > Thanks for pointing out this seeming contradiction and lack of 
clarity.
> >
> >
> > Andreas Veithen wrote:
> >> Section 7.4.2 of ebRIM (version 3.0.1-cd3) specifies that "A Registry
> >> MUST support the query languages as defined by the canonical
> >> QueryLanguage ClassificationScheme." The current version of the
> >> relevant canonical classification scheme defines four query languages
> >> (SQL, Filter query, XQuery and XPath), only two of which are actually
> >> defined in ebRS: SQL and Filter query. Also, section 6.4 of ebRS
> >> (version 3.0.1-cd4) specifies that "An ebXML Registry MAY support SQL
> >> as a supported query syntax within the <rim:queryExpression> element
> >> of AdhocQueryRequest." Only Filter query is declared mandatory by
> >> ebRS. Thus, there is a contradiction between ebRIM and ebRS, unless
> >> the verb "support" in above citation from ebRIM is to be interpreted
> >> in a restricted way (e.g. support to store ad hoc queries in the
> >> registry). Could you clarify this issue?
> >>
> >> Best regards,
> >>
> >> Andreas Veithen
> >>
> >> This publicly archived list offers a means to provide input to the
> >> OASIS ebXML Registry TC.
> >>
> >> In order to verify user consent to the Feedback License terms and
> >> to minimize spam in the list archive, subscription is required
> >> before posting.
> >>
> >> Subscribe: regrep-comment-subscribe@lists.oasis-open.org
> >> Unsubscribe: regrep-comment-unsubscribe@lists.oasis-open.org
> >> List help: regrep-comment-help@lists.oasis-open.org
> >> List archive: http://lists.oasis-open.org/archives/regrep-comment/
> >> Feedback License: 
http://www.oasis-open.org/who/ipr/feedback_license.pdf
> >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> >> Committee: 
> >> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep
> >>
> >> 
> >
> >
> > This publicly archived list offers a means to provide input to the
> > OASIS ebXML Registry TC.
> >
> > In order to verify user consent to the Feedback License terms and
> > to minimize spam in the list archive, subscription is required
> > before posting.
> >
> > Subscribe: regrep-comment-subscribe@lists.oasis-open.org
> > Unsubscribe: regrep-comment-unsubscribe@lists.oasis-open.org
> > List help: regrep-comment-help@lists.oasis-open.org
> > List archive: http://lists.oasis-open.org/archives/regrep-comment/
> > Feedback License: 
http://www.oasis-open.org/who/ipr/feedback_license.pdf
> > List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> > Committee: 
> > http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep
> >
> 
> 
> -- 
> Regards,
> Farrukh
> 
> Web: http://www.wellfleetsoftware.com
> 
> 
> 
> This publicly archived list offers a means to provide input to the
> OASIS ebXML Registry TC.
> 
> In order to verify user consent to the Feedback License terms and
> to minimize spam in the list archive, subscription is required
> before posting.
> 
> Subscribe: regrep-comment-subscribe@lists.oasis-open.org
> Unsubscribe: regrep-comment-unsubscribe@lists.oasis-open.org
> List help: regrep-comment-help@lists.oasis-open.org
> List archive: http://lists.oasis-open.org/archives/regrep-comment/
> Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
> Committee: 
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=regrep
> 





________________________________________________________________________________________________
DISCLAIMER

This e-mail is intended only for the person or entity to which it is 
addressed. It may contain confidential
and/or privileged information. Any copying, disclosure, distribution or 
other use of the content of this
e-mail by persons or entities other than the intended recipient is 
prohibited. Please contact immediately
the sender if you have received this e-mail in error and delete it from 
all locations of your computer. GFI
is validly committed only if the rules on the delegation of powers, as set 
out in the appropriate documents,
have been complied with. Furthermore, due to the risks inherent to the use 
of the Internet, GFI is not
liable for the content of this e-mail if altered, changed or falsified.


- EMD NV, BE 466.107.566
- Adelior Benelux, BE 0.450.798.491, NL 8056.18.302.B.01
- GFI Benelux SA, BE 0.427.608.266, LU 171.204.57
________________________________________________________________________________________________





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