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

[nagahashi@fla.fujitsu.com]

Hi,
(I regret I was unable to attend the refresher session. I'm on a
business trip now)

Thanks Monica for eBA excerpts. I'm happy with adding nuances to a work
item.

Reading DW's followup and Dec. 1st meeting minutes, I'm wondering if I
made my point clear. Let me rephrase my question.
I'm not asking for clarification of  either the ID size or particular
identification system (OMG GUID etc.) to use.

Question is "what should the boundary of ID for each XML element be?
Does it satisfy the requirements to construct globally unique ID by
combining locally scoped IDs?"

We do need globally unique IDs to reference a particular business
process description stored in the registry/repository, but IMO, it is
not necessary for each XML element in BPSS itself to have a globally
unique identifier. Building GUID require extra work by authors/tools.
Possibly overkill.
We can construc t GUID by combining multiple locally scoped IDs with
BPSS document URI --- a la  filesystem path -- and I think this is a
method eBA suggests.

Regards,
Kenji

"Monica J. Martin" <Monica.Martin@sun.com> wroteF
> 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
> >>
> >>
> >>