Re: [ebxml-bp] [ebBP] 3/29/2004: WI-43 Name and NameID Formatting [RSD] Nagahashi Submission

["David RR Webber" <david@drrw.info>]

DRRW@

Monica - on the subject of flattened BODs - clearly CAM can provide
that missing ability to template the use patterns and support context
driven transaction content.

I'm presenting on CAM at OAGi at end of April - so hopefully that
will lead to pilot efforts to use CAM and AOGi V9.0 together.

I've already created a CAM template for an IV&I BOD as an
example.

Thanks, DW.
----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Sent: Monday, March 29, 2004 10:22 AM
Subject: [ebxml-bp] [ebBP] 3/29/2004: WI-43 Name and NameID Formatting [RSD]
Nagahashi Submission


> Discussion|OASIS.ebBP.WI43-Name and NameID;
> Topic|;
>
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200403/msg00104.html;
> Point|Point paper by Nagahashi posted 28 March 2004;
>
> mm1@
>
> Everyone,
> We should discuss the options specified by Kenji in this paper. Martin
> note he has tried to capture your  option here too.
>
> He also makes points to versioning of BPSS elements.
>
>  From a quick read, it appears we have to decide where the business
> requirements lie, with package- or document-based support. We do know
> that we have user community requirements to support packages (such as
> what has been seen in RosettaNet and we are starting to see in
> automotive [1]). That may lend itself to selecting one option over the
> other.
>
> Please post comments to the list or bring your comments to the call
> today. Note, with daylight savings time changes in Europe, times have
> been modified (doesn't affect PST, MST and EST). Thanks.
>
> [1] In automotive, OAG has started to move to what they are calling flat
> BODs that help differentiate the developer (full set of schemas
> required) vs. the end-user package (flattened schema). This correlation
> may not be exact but it does indicate the need for package support in
> BPSS because the logical business document cannot be separated from the
> process it supports (and vice versa).
>
>
============================================================================
=============================================
> ||Point|Last item before summary proposal and vote;
>
>
||Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00250.htm
l;
>
>
||Attachment|http://www.oasis-open.org/archives/ebxml-bp/200402/msg00224.htm
l;
>
>
> ||Remember in this, as requested by Dale Moberg, to indicate whether
> Name or Name ID is being referenced in order This assists code processing.
>
> ||John Yunker, we need your feedback on this one that we have met your
> use case.
> ||Kenji Nagahashi, Martin had proposed previously three types could be
> used. We discussed two in our meeting in the last few weeks (see
> previous email below). Which ||option do you and Martin believe will be
> the most accessible and flexible for the user?
>
> ||Roberts, February 2004:
> ||1. Unique Id: Id must be universally unique, need not be human
> friendly and used only to identify the object in a unique unambiguous
> manner. The Id must not be ||overloaded to contain any encoded
information.
> ||2. Human Friendly Name: In the registry this can be any String and
> need not be unique at all.
> ||3. External Identifier: A unique value within a unique namespace that
> serves as an identifier for the object.
> ||An example is the DUNS # for a company within the DUNS namespace.
>
> ||Previous email summary vote information:
> ||mm1@
> ||The fifth Work Item for summary closure is:
> ||Work Item 43 Name and NameID [Use of GUID and GUIDREF (Use of name
> and/or id for reference elements)]
> ||
> ||Work Item Summary
> ||In the BPSS Schema 1.01 and 1.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.
> ||
> ||Relates to WIs:
> ||None identified.
> ||
> ||Summary Resolve
> ||a. Provide the capability for internal and external uniqueness of a
> BPSS instance.
> ||
> ||Note: In meeting 8 March 2004, we discussed that both a NameID (allow
> late binding) and UUID (guaranteed to work and be pre-resolved) could be
> used but would add ||additional complexity. Therefore, we need to ensure
> we provide the capability to handle the use cases and minimize level of
> complexity. We need to be able to use the ||same Name with two IDs. One
> solution was to use an UUID and append to an IDREF. UUID is unique
> because it includes an IP address as part of its root. Globally ||unique
> in the context of the creator, per Yunker.  Nagahashi commented that an
> IDREF could be combined with identifiable BPSS instance. Does this meet
> the ||requirements for internally (local) and externally unique reference?
> ||
> ||Open Items
> ||v3.0: Revisit for the ProcessSpecification.
> ||
> ||***Kenji Nagahashi/John Yunker: We are pending your comments on
> Roberts' proposal as discussed 8 March 2004 and verification this fits
> your us cases.***
> ||
> ||The ballot on this item will not be opened until I get an answer from
> Kenji/Martin/John Y. Thanks so please provide comment.
> ||@mm1
>
> @mm1
>
>
 @DRRW