Re: [ebxml-bp] Comments on NameID/IDRef and UID and Late Binding and Document References

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

Martin,

On this whole topic of late binding what you are saying
makes total sense for me.

I believe you are echoing the same thoughts as I proposed
in the draft I posted on using a supplementary XML instance
to capture the context and parameters needed to clarify the
interchange details within a BPSS process.

I'm re-posting here that attachment - in case you had
not seen that already - and I'm hoping this either makes
sense, or you can provide feedback on that.

I also updated somewhat to make it clearer and more
focused on the BPSS use cases.   We may want to add
more such use cases beyond the simple one I illustrate
in Figure 3.2 for the Time-To-Respond example.

Thanks, DW.

----- Original Message ----- 
From: <martin.me.roberts@bt.com>
To: <ebxml-bp@lists.oasis-open.org>
Sent: Monday, January 26, 2004 12:17 PM
Subject: [ebxml-bp] Comments on NameID/IDRef and UID and Late Binding and
Document References


Dear all,
I have s ome comments on these two issues.  I realise that
decisions have been made on the nameID but I felt it might be worth
reiterating my views.

NameID and IDRef and UID.  - I have found through experience
that with tools ID and IDRef are the best way to go.  However, I have
found that until tools are available and for some background editing the
NamID seem to be the best answer for humans.  So the decision we have to
make is where the effort will be placed in creating BPSS files.  If we
think the majority will be through tools (we use Bind Studio) then IDs
are where we should go.  If we feel human intervention will be still the
main tool then we need to go down the nameID route.

This still leaves the UID question.  I like the idea that UID
similar to the ones David Webber published as I as a human can sytill
manage a 6digit number.  I have no hope of managing a GUID of 128K!!.
We in BT have used the UID for all our document meta data and it has
proved very easy to manage both for machines and humans.


Late Binding has some interesting and curious requirements.  We
tried to model the ordering process in BT.  We found that the use of the
overall TimeToPerform for a BinaryCollaboration was unworkable.  If I
have a PO that has a standard lead teim of 5 days do I set the TTP to 5
days?  But what happens if the customer does not want their goods for
30days.  The process would time out.  So I would like to treat all Times
and possible documents as being variables that may, but not necessarily,
be overidden by data sent within the Business Documents.  At the moment
there is lots of data that is passed between our customers that effect
the times and documents which we can not use as there is no way to
reference that information within the BPSS.

One interesting issue that would be also good to influence would
be the sending of a receipt.  I feel a partner should be able to say I
am not interested in a receipt.  In this way they take the risks but
may be enjoy a simpler interface.

Lastly references to documents from within the BPSS.  In version
1.01 and CEFACT V1.1 this is a definite weakness.  We have ended up
using a naming convention to reference more details of what is required
within a document.  Personally as you might expect from a CAM team
member I am not keen on XSD, but I feel that the majority of people
would expect support for things such as WSDL and XSD  Therefore I would
like to see a discussion around having a pointer either to a BPSS
supplement that is just for documents or some extra information within
the BPSS document section that allows for better links to various
document descriptions techniques.  The sort of extra data is things like
allowing parameters to be passed into a tool to resolve the document
definition, the abilty to reference sites where more details
documentation is given.  The ability to include a list of possible
documents that satisfy this transaction.

I am hoping to be there next week.


Martin Roberts
xml designer,
BT Exact
e-mail: martin.me.roberts@bt.com
tel: +44(0) 1473 609785  clickdial
fax: +44(0) 1473 609834
Intranet Site :http://twiki.btlabs.bt.co.uk/twiki



-----Original Message-----
From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
Sent: 26 January 2004 15:21
To: Kenji Nagahashi; Jean-Jacques Dubray; Yunker, John
Cc: Dale Moberg; ebXML BP
Subject: [ebxml-bp] Yunker/Nagahashi 1/26/2004: Question on Construction
of GUIDREF / Versioning



> mm1: Kenji,
> With this proposal and today's TC call and vote, can you agree on
> final verbiage with John Yunker to ensure we capture his comment on
> name (item 3 below):
>
>    * Leave specification as is.
>    * Do not specify what UID is.
>    * ***Clarify: Can use name and perhaps give example of a condition
> when used.***
>
> I have also attached John's response. I think we pretty much have
> consensus except for the versioning question, Work Item 7.

mm2: For Work Item 43, have you had any luck so we can discuss in
today's call? In addition to the response from Dave Webber [1], I've
also included the initial response from Reg/Rep. We should think
carefully before embedding information as suggested. John, can we have
your response so we can finish this (see ***clarify.....***)?

Related and for Work Item 7, in addition, the ebXML JC is considering a
larger-scale compatibility matrix that may be affected by/affect our
discussion on UID and/or versioning. We may also look to RIM on how it
sees versioning as I think it will come to a common solution between all

the ebMXL TCs at some point.

Thank you.

[1] attached

>-----------------------------------------------------------------------
>-
>
>Subject:
>RE: [ebxml-bp] Nagahashi 1/7/2004: Question on Construction of GUIDREF
>From:
>"Yunker, John" <yunker@amazon.com>
>Date:
>Mon, 19 Jan 2004 11:12:47 -0800
>To:
>"Monica J. Martin" <Monica.Martin@Sun.COM>, nagahashi@fla.fujitsu.com
>CC:
>ebxml-bp@lists.oasis-open.org
>
>BPSS components have a name attribute, and the reference elements
>reference both a name and an ID.  Not sure what you mean by "not used
>for referencing BPSS components".
>
>Since IDs change when versions change (there is no version element in
>naming) and are maintained by software, the name reference is the only
>element that allows binding over version, domain (e.g. industry group),

>and usecase boundaries.
>
>Monica, I'm still in the midst of 2004 planning with all day meeting,
>and appologize for not being on todays call.
>
>John
>
>-----Original Message-----
>From: Monica J. Martin [mailto:Monica.Martin@Sun.COM]
>Sent: Monday, January 19, 2004 11:58 AM
>To: nagahashi@fla.fujitsu.com
>Cc: ebxml-bp@lists.oasis-open.org
>Subject: Re: [ebxml-bp] Nagahashi 1/7/2004: Question on Construction of
GUIDREF
>
>
>nagahashi@fla.fujitsu.com wrote:
>
>
>
>
>>>Nagahashi: Hi,
>>>
>>>- name attribute carries descriptive text only. It is never used for
>>>referencing BPSS components. It is not required to be unique at all,
>>>even within a package.
>>>
>>>
>>>
>
>mm1: Need input from John Yunker on this one.
>
>
>
>
>>>Any thoughts?
>>>
>>>
>>>
>>>
>
>mm1: We can discuss in today's call to come to closure. Thank you.
>
>
>
>
> ----------------------------------------------------------------------
> --
>
> Subject:
> Re: [ebxml-bp] Nagahashi 1/7/2004: Question on Construction of GUIDREF
> From:
> nagahashi@fla.fujitsu.com
> Date:
> Mon, 19 Jan 2004 10:50:05 -0800
> To:
> ebxml-bp@lists.oasis-open.org
>
>
>Hi,
>
>Sorry to be late. I was reading discussions on work item 43.
>Here's my proposal for resolution of the work item.
>
>There are two points to address:
>- double reference with name and nameID
>- uniqueness rule for nameID (or name), i.e. scope of nameID.
>
>Terms:
>- BPSS components: such as BinaryCollaboration, TransactionActivity.
>- GUID: general term for globally unique identifier. UUID is a specific
>example of GUID. Identifiers only unique within a document or package
>are not GUIDs.
>- UUID: 128bit globally unique identifier defined by DCE. Used in ebRR.

>
>Proposal:
>
>- Use only nameID for referencing BPSS components.
>
>- BPSS specification doesn't enforce any specific format for nameID.
>Author may use arbitrary text (as far as it satisfies other rules).
>
>- name attribute carries descriptive text only. It is never used for
>referencing BPSS components. It is not required to be unique at all,
>even within a package.
>
>- Scope of nameID is a package. So reference to BPSS components (within
>the same document) MUST be qualified with package names. As a special
>case, qualification is not necessary for reference to BPSS components
in
>the same package. This means nameID is not a GUID (as defined above)
--- 
>so type name for nameID should not contain "GUID" to avoid confusion.
>
>- external descriptions (eg CPP/A) reference BPSS components by
>combination of
>  1. globally unique identifier for BPSS document (eg. URL, or UUID
>assigned by ebRR)
>  2. fragment = <package name> '.' <nameID>
>
>  (example: http://host.domain.com/brabra/process.xml#package.PO)
>
>Any thoughts?
>
>Regards,
>Kenji Nagahashi
>
>

OASIS-BPSS-Specifications-Context-Management.doc