Inconsistency in section 6.3.2 of ebXML RS, version 3.0.1-cd3

[andreas.veithen@gfi.be]

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.

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

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

In conclusion, I think that these changes in version 3.0.1 are a 
regression with respect to the original version. 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.

Best regards,

Andreas Veithen 




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