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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep message

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


Subject: RE: [regrep] Re: Need missing figures


Thanks Farrukh. The listing issue is still confusing. In the v3.0-os the
line number is 1871, and the text under the example is: "Listing 2:
Example of Stored Query Invocation." The section is 6.3.2.1 Specifying
Query Invocation Parameters. I just want to make sure that this is the
same thing as the issue, since the text in the issue is "Listing 2:
Example of
AdhocQueryRequest to a Parameterized Ad hoc Query" . 

Sorry to be such a pain!

Kathryn


Kathryn Breininger
Boeing Library Services
425-965-0182 phone




-----Original Message-----
From: Farrukh S. Najmi [mailto:farrukh@wellfleetsoftware.com] 
Sent: Monday, December 18, 2006 4:07 PM
To: Breininger, Kathryn R
Cc: ebXML Regrep
Subject: Re: [regrep] Re: Need missing figures

Breininger, Kathryn R wrote:
>  Farrukh,
> Can you point out for me which document (RIM or RS) and on which line 
> numbers these two item appear:
>
> *	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
>   

Above is on line 1850 in ebRS (search for "Listing 2")

The replacement listing can bet gotten from:

<http://ebxmlrr.cvs.sourceforge.net/*checkout*/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).
>   

See section 5.1.2 line 1143:

Old Text:

"A Submitter MAY optionally supply the id attribute for submitted
objects. If the Submitter supplies the id and it is a valid URN and does
not conflict with the id of an existing RegistryObject within the home
registry then the registry MUST honor the Submitter-supplied id value
and use it as the value of the id attribute of the object in the
registry. If the id is not a valid URN then the registry MUST return an
InvalidRequestException. If the id conflicts with the id of an existing
RegistryObject within the home registry then the registry MUST return
InvalidRequestException for an UpdateObjectsRequest and treat it as an
Update action for a SubmitObjectsRequest.
If the client does not supply an id for a submitted object then the
registry MUST generate a universally unique id. A registry generated id
value MUST conform to the format of a URN that specifies a DCE 128 bit
UUID as specified in [UUID]:
(e.g. urn:uuid:a2345678-1234-1234-1234567890"

New Text:

"A Submitter MUST supply the id attribute for submitted objects. If the
Submitter supplies the id and it is a valid URN then the registry MUST
honor the Submitter-supplied id value and use it as the value of the id
attribute of the object in the registry. If the id is not a valid URN
then the registry MUST treat it as a temporary id and replace it, and
all references to it within the request, with a registry generated
universally unique id. A registry generated universally unique id value
MUST conform to the format of a URN that specifies a DCE 128 bit UUID as
specified in [UUID]:
(e.g. urn:uuid:a2345678-1234-1234-1234567890"

Above text removes the inconsistency with rim.xsd. Recall in such cases
we state that XML Schema file always wins over spec verbeage.
So the spec was in a tolerable state with respect to this issue. We
should fix it nevertheless.

Thanks.

--
Regards,
Farrukh

Web: http://www.wellfleetsoftware.com




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