Comments about ebRS

[andreas.veithen@gfi.be]

Dear all,

Please find below some additional comments about the "ebXML Registry 
Services and Protocols" (ebRS) specification, version 3.0.1-cd4.

* Sections 5.1 and 5.2 miss some crucial information about how repository 
items are submitted. While it seems obvious that they are submitted as 
attachments to the SOAP message, it is not clear how registry objects and 
repository items submitted as attachments are linked together inside a 
same request. Indeed, suppose I want to submit a set of ExtrinsicObjects 
together with their corresponding repository items. How am I supposed to 
specify which attachment corresponds to which ExtrinsicObject? The example 
provided in section 10.3.2.6 suggests that this is done by specifying the 
ID of the repository item (which is also the ID of the related registry 
object) in the Content-ID header of the attachment. If this is correct, 
then it should be specified in sections 5.1 and 5.2. However, it should be 
noted that this usage of the Content-ID header field would be in 
contradiction with the SOAP protocol. Indeed, for the syntax of the 
Content-ID header field, the SOAP specification explicitely refers to 
RFC2045, which describes it as "syntactically identical to the Message-ID 
header field". The syntax of Message-ID is defined by RFC822 in the 
following way:

"Message-ID" ":" msg-id
msg-id = "<" addr-spec ">"
addr-spec = local-part "@" domain

It is clear that in general a repository item ID will not be compatible 
with this syntax because it will not match addr-spec.

* The definition of the possible values for returnType in section 6.1.4.2 
requires some clarification, in particular RegistryObject and LeafClass. 
What is the definition of a leaf class? Is Slot a leaf class? If a query 
matches a Service object and returnType is RegistryObject, what is the 
expected response?

* Sections 6.4 and 6.5 defining SQL and filter query syntax don't 
explicitely link the syntaxes to classification nodes in the canonical 
QueryLanguage classification scheme. Even if the correspondence is 
obvious, for completeness ebRS should mention that the queryLanguage 
values are urn:oasis:names:tc:ebxml-regrep:QueryLanguage:SQL-92 and
urn:oasis:names:tc:ebxml-regrep:QueryLanguage:ebRSFilterQuery 
respectively.

* Section 6.4 states that "A <derived column> MAY NOT have an <as 
clause>." The usage of upper case suggests that "MAY NOT" has a precise 
meaning according to RFC2119, which it has not.

* Section 8.10 states that "The canonical XML Content Cataloging Service 
MUST apply the XSLT style sheet to the input XML instance document(s) in 
an XSLT transformation to generate the Cataloged Output." However, it is 
not specified what should be the root element of the output of the XSL 
transformation. Given the structure of cms:CatalogContentResponse, one 
would guess that the root element should be cms:CatalogedContent. However, 
according to cms.xsd, cms:CatalogedContent is not a valid root element, 
implying that the XSLT would produce output that can't be validated using 
a schema. Also, OMAR requires the output of the transformation to have a 
valid root element with type rim:RegistryObjectListType, leaving as only 
option rim:RegistryObjectList. If this is the correct choice, then a 
corresponding requirement should be added to ebRS.

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
________________________________________________________________________________________________