Re: [ebxml-bp] BPSS 1.01 XML Schema element referencing with idandname issue

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

Monica,

Looking at the section that you provide below - I believe we are OK here.

My interpretation is that people can use OMG style GUIDs if they wish - but
they are not mandated. It appears that any system that provides a globally
unique reference is acceptable. Further more - these appear to only be
required when external references are made to BPSS components -
and again that makes sense too.  Clearly a closed local system that cannot
be
reference globally - so in that there cannot be issues with parties using ID
systems
that they prefer.  Also - we'd expect industry groups to use systems they
are comfortable with and probably already have - RosettaNet, EDI and OAGI
all come to mind.

This being an OASIS based effort - I see we are on track here to
in producing the supporting content and views that implementers
need:

1) outreach materials - overview of BPSS - (done), trifold and brochures
2) learning sessions and materials - in progress
3) updated BPSS schema
4) revised specifications
5) appendix of use cases and examples - in progress
6) implementation notes and recommended practices.

And obviously as we organize and garner this we be achieving our
goals from the perspective of the charter.

Thanks, DW.

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: <nagahashi@fla.fujitsu.com>
Cc: <ebxml-bp@lists.oasis-open.org>
Sent: Friday, November 28, 2003 8:25 AM
Subject: Re: [ebxml-bp] BPSS 1.01 XML Schema element referencing with
idandname issue


> nagahashi@fla.fujitsu.com wrote:
>
> >Hi
> >
> >Let me ask quick (and possibly silly) question: Do you really mean
> >128byte, OMG style, true globally unique identifier, by "GUID"?
> >
> >From the Anders' comments Monica posted and JJ's comment, I understood
> >what we really need is identifiers which is unique within a *package*.
> >ebXML architecture only requires that key elements of BPSS
> >(BinaryCollaboration, Transitions, Business states, ...) are uniquely
> >identifiable from other document. That is we can use the file and
> >package as identifier scope. I understood we need  IDs which is unique
> >within package (so xs:ID won't work), but 128byte GUID is too much. Am I
> >missing some important requirements?
> >
> >
> mm1: Kenji, perhaps we need to clarify explicitly what our boundary of
> 'globally unique.' I've included a few relevant references from the BPSS
> (1.1) and eBA (0.83):
>
> [bpss] Section 6.3
> Two types of attributes are provided for names and references, XML
> GUID/GUIDREF based and plain text. Each named element has a required
> name attribute and an optional nameID attribute. Referencing elements
> have lowerCamelCase and lowerCamelCaseIDREF attributes for the
> referenced element. XML 2367
> GUID/GUIDREF functionality requires all IDs to be globally unique and
> that all GUIDREFs point to a defined GUID value.
>
> [eba] Section 5.2
> The received Trading Partner Profile contains references to at least one
> business process. Such references SHALL be done by a Globally Unique
> Identifier (GUID) that can be subsequently used by the first Trading
> Partner to query the Registry for a reference to the Business Process
> instance. Although a GUID reference is required, other reference methods
> may be additionally used.
>
> Section 7.4
> The type of reference used by the Trading Partner Profile and Trading
> Partner Agreement documents to locate the Registry containing the
> metadata necessary to retrieve a Business Process Runtime Expression MAY
> be accomplished by use of a Globally Unique Identifier (GUID). The
> Globally Unique Identifier SHOULD contain three items: 1. The URI for
> the Registry, 2. An Identifier which is unique within that Registry.......
>
> It appears we have some flexibility in the references and what
> boundaries we extend on the GUIDREF:
>
>     * Unique within a package
>     * Unique within a registry
>     * Globally unique (unspecified)
>
> I believe our intent was the first choice [1], however, I will add this
> nuance to the existing new Work Item from Sacha. Any updates we make
> will not only affect the schema but the sections that reference GUIDREF.
> Thanks.
>
> [1] Reference: 1.1, Section 6.3.
>
> >Thanks
> >Kenji
> >
> >"David RR Webber" <david@drrw.info> wroteF
> >
> >
> >>Serm',
> >>
> >>Yes - OK - we're all on the same page here then.  I just find it
> >>disconcerting when the real name is some 20 or 30 bytes long
> >>and the 'short hand' reference to it is just a mere 128 bytes long!
> >>
> >>Thanks, DW
> >>
> >>
> >>
>
>