RE: [ebcore] PartyId Type remark

The previously agreed upon formats for party-id-type identifiers need to be retained because of votes made in ebCPPA TC. Most of the previous procedures for constructing identifier values were formulated by ECOM, and certain fine points arising from URI character set restrictions were added.

Possibly the first paragraph needs to emphasize some background context:

0. Legacy identifiers are not URIs so TC asked to suggest a way to produce URI reflecting legacy naming identifier schemes (registered with ISO…)

1. Preservation of old procedures and identifiers is accepted good practice.

2. New procedure and new “naming (sub) authority”. using the “ebcore” substring as mentioned below.

3. Reminder that these identifiers are supplied as guidance in using existing naming authorities registered with ISO, and the procedures are not in any way meant to prevent community or even bilateral agreements on other URI values for party-id-type codes (this is clearly how ebMS left it).

Should anything be said about using non-ISO codes for naming authorities? Will there be yet another set of codes for naming authorities for systems of identifying organizations? I would say that we just wait and see on that. Meanwhile, people are still free to invent URIs in their own URI naming authority space if they wish.

From: David RR Webber (XML) [mailto:david@drrw.info]
Sent: Tuesday, March 23, 2010 8:09 AM
To: Sander Fieten
Cc: ebcore@lists.oasis-open.org
Subject: RE: [ebcore] PartyId Type remark

Sander,

I agree.

No need to restrict this too much for users - instead need to offer clear guidelines on schemes to use to derive consistent URNs.

Thanks, DW

-------- Original Message --------
Subject: [ebcore] PartyId Type remark
From: Sander Fieten <sander@fieten-it.com>
Date: Mon, March 22, 2010 4:46 pm
To: "ebcore@lists.oasis-open.org" <ebcore@lists.oasis-open.org>

All,

The remark I tried to explain on last Friday’s call is about the general structure of the URN that’s being specified. As I already mentioned in my earlier e-mail about the first draft the general scheme looks like urn:oasis:tc:ebcore:partyid-type:[<catalog-identifier>:]<scheme-id within catalog>. The section on forming URN’s based on the ISO6523 scheme are not [all] consistent with this scheme.

Furthermore I think this general scheme can be used generally and not restricted to the three schemes currently defined in the draft. This would allow greater flexibility. For example this allows easy extension to government regulated schemes, like personal or businesses identification numbers. If we don’t want to create an “open ended” scheme, I think it can be usefull to add a category for such government regulated naming schemes.

Regards,
Sander

ebcore message