[Fwd: Re: [regrep-comment] Inconsistency in section 6.3.2 of ebXMLRS, version 3.0.1-cd3]

[Farrukh Najmi <farrukh@wellfleetsoftware.com>]

Dear colleagues,

I am taking full responsibility for this oversight during the review of 
3.0.1 and errata. My apologies.

Attached is a fixed version of 3.0.1 (I call is cd4) for your review. 
The changes are very small and shown in changebars under section 6.3.2 
"Invoking a Stored Query".

Please review it quickly as this is a mistake we should fix ASAP.

Kathryn, we probably ought to rev the errata with same change ASAP.

Again, I am sorry for this mistake.

-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com

regrep-rs-3.0.1-cd4.pdf

--- Begin Message ---

• From: Farrukh Najmi <farrukh@wellfleetsoftware.com>
• To: andreas.veithen@gfi.be
• Date: Thu, 23 Aug 2007 08:54:53 -0400

Hi Andreas,

Thank you for your valuable feedback. Please see more inline below.

andreas.veithen@gfi.be wrote:
> Dear all,
>
> There is an inconsistency in version 3.0.1-cd3 of the "ebXML Registry 
> Services and Protocol" specifications related to stored queries. More 
> precisely, the example given in Listing 2 in section 6.3.2.1 is in 
> contradiction with what is specified in the introductory paragraph of 
> section 6.3.2:
>
> * 6.3.2 specifies that "the <rim:AdhocQuery> element MUST not contain a 
> <rim:queryExpression> element", but the example in Listing 2 contains a 
> <rim:queryExpression> element.
>
> * 6.3.2 specifies that "the <rim:AdhocQuery> element's id attribute value 
> MUST match the id attribute value of the stored query", but in the 
> example, the id of the stored query is provided in a request slot and the 
> id attribute of the <rim:AdhocQuery> element is "temporaryId".
>
> * 6.3.2 specifies that "the <rim:AdhocQuery> element MAY have a Slot for 
> each non-context parameter defined for the stored query being invoked. 
> These Slots provide the value for the query parameters." In the example 
> however, these parameters are not provided as part of the <rim:AdhocQuery> 
> element, but of the <rs:RequestSlotList> element.
>   

You are absolutely correct on all counts above.
We came to realize this mistake quite recently (earlier this week) 
unfortunately.

> It should be noted that in version 3.0 of the standard, the example in 
> Listing 2 was entirely consistent with the specification. On the other 
> hand version 3.0.1 of the OMAR reference implementation only accepts 
> AdhocQueryRequests as shown in the new version of the example, but rejects 
> messages consistent with the specification (and the old version of the 
> example).
>   

Actually OMAR had implemented the wrong behavior probably as far back as 
version 3.0-beta1 more than 2 years ago :-(

> The content of the 3.0.1 version of the example also raises two additional 
> questions:
> * What is the meaning of the id attribute of <rim:AdhocQuery>? In the 
> example it is set to "temporaryId", suggesting that it is only there 
> because it is declared mandatory in the XML schema but should be ignored 
> by implementations in this context. This seems to be bad practice.
>   

The textual description (copied below) is correct and the listing is 
wrong as you point out.

"

    *

      The <rim:AdhocQuery> element's id attribute value MUST match the
      id attribute value of the stored query.

"

> * The example also shows a <rim:queryExpression> with a queryLanguage 
> attribute. This doesn’t make sense for a stored query because the 
> underlying query language should be transparent to the client.
>   

Again you are correct.

> In conclusion, I think that these changes in version 3.0.1 are a 
> regression with respect to the original version. 
I agree.
> Also, this change gives 
> the impression that the specifications have been modified to match the 
> behavior of the OMAR reference implementation, whereas OMAR should have 
> been modified to match the specifications.
>   

Several of the spec contributors (including myself) are also 
contributing to OMAR.
We try to properly and diligently balance the spec and implementation 
roles.

In this case it was really just an honest mistake that we did not notice 
the discrepancy with the spec in OMAR and used an already available XML 
document from OMAR as an example for the spec.

We will address this important issue in another errata and in the next 
version of the spec. As an aside I will also communicate to the OMAR 
team to make OMAR 3.0.2 comply with the spec once the issue you 
identified is fixed.

Thanks again for this valuable feedback.

-- 
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

--- End Message ---