RE: [ebxml-bp] [ebBP] 5/31/2004: Get out the vote for WI-43-66 [RSD]

["Steve Capell" <steve.capell@redwahoo.com>]

Hello all,

I'm not eligible to vote on this but I thought I'd make a few comments for
voting members to consider.

First I want to point out there are two very distinct use cases for BPSS (at
least in our framework):

1	As a machine readable description of a process that is consumed by a
BSI in order to manage compliance to a public process.
2	As a serialization format of a UN/CEFACT UMM model that is published
to a registry AND is used as the source of key registry meta-data (ie
registry GUIDs) that will get extracted from the content of the BPSS when
submitted to the "publish public process" interface of the registry.

With that in mind I think:-

1	In general globally scoped UUID's as NameID for every element that
needs to be referenced from somewhere is a bad thing.  They make documents
unreadable because the UUIDs (typically uri's) are typically very long.  I
attach a sample bpss from one of our projects (Australian grain industry)
that makes liberal use of uuids so you can see what I mean.   So from the
perspective of use case #1, I fully support this proposal to make nameId a
document scoped xsd:id.

2	However the globally scoped uuid is useful because it can be a
properly formed urn and can be used as the registry key (which needs to be a
globally scoped ID) during publishing operations.

So I see the xsd:id as the ideal mechanism for runtime operation of the bpss
and should be used wherever an element needs to be identified for reference
from other elements.

But I see the UUID (implemented as a properly formed urn) as a kind of
"documentation" attribute that could be usefully associated with key
elements like <binary collaboration>/<role> in order to support meta-data
extraction for registry publishing operations.

So by all means lets use xsd:id for element identification but lets keep the
capability to add a urn to some elements to support registry meta-data
extraction.

I hope this all makes sense - apologies if I've misunderstood something
because I'm no expert in this area, just a humble user trying to deploy an
ebXML architecture in a repeatable & scalable way.

Steve Capell
Red Wahoo Pty Ltd
+61 410 437854

-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
Sent: Tuesday, 1 June 2004 1:32 PM
To: ebXML BP
Subject: [ebxml-bp] [ebBP] 5/31/2004: Get out the vote for WI-43-66 [RSD]
Importance: High

OASIS.ebBP.WI-43-66-Name and Name ID Clarification;
Topic|;
Point|Quorum Vote Opened 31 May 2004;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200405/msg00147.html;

mm1@
The vote for this work item today and will continue to 8 June 2004.

Original Work Item 43 (encompasses 66):
In the BPSS Schema v1.01 and v1.1 elements can be reference either by 
their name or their ID (or GUID). Seems one is redundant and ID's 
(GUIDs) normally used to reference other elements. Do GUID's help XML 
parsers? Use of GUID and GUIDREF could lead to processing errors. 
Identify or recommend if acceptable for CPPA or allow them to also 
decide on this (for CPA negotiation). Given resolve, specify explicitly 
if the scope of global uniqueness for GUIDREF.

Vote Question:
============================================================================
============ 

Do you agree that:

The BPSS SHOULD support the use document-scoped nameID attribute for 
reference solution (Solution 2) with the distributed amendment:
[See Nagahashi submission under References].

NameID: NameID is xsd:ID. NameID is Document-scoped, regardless of 
package structure. Since NameID is document-scoped, no qualified 
identifier syntax is required. The NameID MUST be used for reference 
purposes.

Name: The Name attribute MAY be mandatory. Name attribute MAY be unique 
within a BPSS document. The use of Name attribute is used by CPPA v2.0 
to reference BPSS elements. The Name SHOULD NOT be used by other BPSS 
elements for reference purposes. The Name type is xsd:string and 
arbitrary text is allowed.  Use cases for visualization, CPPA and 
another identified requirements will dictate whether or not the Name is 
required. Whether or not the Name is mandatory or optional will be 
further investigated. At this time, the Name attribute SHOULD be required.

The technical specification SHOULD clearly specify the use of Name and 
NameID. In addition, a implementor's note or hint SHOULD be given to 
ensure care is taken to make NameID unique within a document (such as 
embedding package name in NameID). 
============================================================================
============ 

References:
Summary proposal for vote: 
http://www.oasis-open.org/archives/ebxml-bp/200405/msg00147.html

@mm1