OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-bp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hi all,

See my comments below (only for name/nameID issue).

> 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.

<KN> That's the motivation behind my proposal.
First I let me clarify: nameID *IS* IDREF. I understood you meant "we 
need to go down the name route". Is it right?

One of my proposal is this: Let us not force people to use 
NON-human-friendly string for nameID attribute.
Those who authoring BPSS document by hand can use easy-to-understand 
string for nameID, as far as they maintain uniqueness within a package.

BPSS tools may use human-unfriendly string for nameID. But again, it is 
not required to follow UUID or UID or any other standard identifier 
scheme  for global uniqueness. It is only required to be unique within 
package.

So problem arise only when a BPSS hand-crafter have to read BPSS 
authored by tools.
If we want to address this issue as well, using both nameID and name for 
referencing may be the only solution.
And it was the start of this issue that it is cumbersome and error-prone 
to maintain two kinds of referencing scheme.
</KN>




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]