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


Help: OASIS Mailing Lists Help | MarkMail Help

ebcore message

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

Subject: Re: [ebcore] PartyId Type remark


I agree that previously agreed upon formats should still be supported by this spec. However this spec now defines a general scheme for constructing URN's to identify naming schemes / authorities. Currently the spec is restricted to just three schemes, and one unregistered. There're however more naming schemes  that are regulated / registered, for instance schemes defined by law. Why not use the general structure as defined in the spec to create URN for such schemes? I don't think it requires a lot change to the spec, but increases it potential usage a lot.


On 23 mrt 2010, at 16:26, Moberg Dale wrote:

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


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.

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

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