Re: [regrep] Meeting reminder and draft agenda

["Farrukh S. Najmi" <farrukh@wellfleetsoftware.com>]

Breininger, Kathryn R wrote:

This is a meeting reminder and draft agenda for our ebXML Registry TC
meeting Thursday, October 26th, at 8:00am PT.  Please send any
additional agenda items. 
 
The telecon number and password:
USA toll: 1-210-795-0625
USA Toll free: 866-617-3597
PARTICIPANT PASSCODE (same for all countries): 1739140 

International numbers;
France
Toll: 33-1-70-70-84-56
Toll free: 080-510-0984
UK
Toll: 44-20-7108-6391
Toll free: 0800-279-9632 

For other countries please contact Kathryn Breininger directly (sorry,
the vendor does not have a number for Turkey yet..).

Draft Agenda:
1. Approval of previous meeting minutes for September 28th

2. Minute taker 

3. ebXML Registry Profile for Web Ontology status

4. User Guide for profiles status (see minutes from last meeting) 

5. ebXML Registry 3.0 issues
<<<http://www.oasis-open.org/archives/regrep/200606/msg00006.html>>>

  

The latets short list of bugs is present here:

<http://ebxmlrr.sourceforge.net/wiki/index.php/Spec/regrep#Bugs_in_ebXML_Registry_specs>

I am copying the current list inline below for ease of reference...

Bugs in ebXML Registry specs

• Many figures are missing ebRIM and ebRS

• Need to provide a normative and consistent way to handle VARCHAR columns that exceed the specified fixed lentgth. Currently the big issue is with query column in AdhocQuery table which run into limit of 4000 characters in Oracle db. Suggest using a spillover algorithm where if string does not fit it is written to a RepositoryItem and the id of spillover RepositoryItem is written in teh field value instead.

• ObjectRef in the ebRIM spec is overloaded (in 2.2 it is a data type, in 2.7 it is a class). Also, should check in both ebRIM and ebRS all usages of the keyword "ObjectRef" and make sure that semantics is correct.

• The stored query given in "Listing 2: Example of AdhocQueryRequest to a Parameterized Ad hoc Query" should be replaced with the one in the /cvsroot/ebxmlrr/omar/misc/samples/StoredQueryInvocationExample.xml

• "A Submitter MAY optionally supply the id attribute for submitted objects" the paragraph suggests that id attribute of Identifiable is optional when it is actually not so according to rim.xsd (from Andrzej). The rim.xsd is correct and paragraph is wrong (from Farrukh).

Andrzej responds: I'm not sure you should be so quick to judge this a bug/mistake. I can see many scenarios where it would be very convenient to be able to create objects where you specify only the lid and have the registry generate the unique id (uuid). We have a number of those in the project I'm working on. I think it's a valuable feature and that the spec is correct as written. If the application doesn't care what the id is, why should we have to specify it, when the registry can easily generate a unique UUID on our behalf? This doesn't make any sense to me. From a practical users perspective I vote a strong -1 on making this a bug! And +1 one on changing the implementation to suit the spec. I think the implementation is incorrect and the spec is just fine. Andrzej's argument makes sense (Nikola), but question is what to do with the rim.xsd as "id" is required under "IdentifiableType".

• PersonName attributes FirstName, MiddleName and LastName SHOULD be InternationalStrings. Use case: a user MAY want their PersonName.FirstName/MiddleName/LastNames to appear in two different locales. For example: a Chinese user may want his name to appear in zh for Chinese users and in en for US users.

• PostalAddress is missing a type attribute that allows classifying the PostalAddress. Noet that TelephoneNumber and EmailAddress are OK.

-- 
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com