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

 


Help: OASIS Mailing Lists Help | MarkMail Help

bdxr message

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


Subject: Examples in SMP 1.0 specification


Dear all

 

Responding to the comment received from Martijn van den Boogaard about updating examples to include OASIS ebCore Party ID scheme identifiers (see: https://lists.oasis-open.org/archives/bdxr-comment/201605/msg00005.html), I’m proposing to implement the below changes to the specification.

 

I feel that the comment from Martijn is relevant and that the ebCore Party ID specification (https://docs.oasis-open.org/ebcore/PartyIdType/v1.0/PartyIdType-1.0.odt) is more broadly useful than the PEPPOL specific examples, and it will make us consistent with the BDXR TC charter: “Wherever possible, the TC specifications are based on profiles of existing standards from OASIS and elsewhere.”. I’m also thinking that if the ebCore Party ID specification had been made before PEPPOL developed the original version of the SMP specification, we would probably have used it there as well instead of coming up with our own scheme identifier for participant IDs. Please let me know your thoughts and comments.

 

These are the changes I’m proposing:

 

1) Insert ebCore Party ID as non-normative reference:

 

[ebCorePartyId]

“OASIS ebCore Party Id Type Technical Specification Version 1.0. OASIS Committee Specification”, September 2010, https://docs.oasis-open.org/ebcore/PartyIdType/v1.0/PartyIdType-1.0.odt

 

2) Section 2.3.4.3: Change examples to:

http://smp1.eu/urn%3Aoasis%3Anames%3Atc:ebcore%3Apartyid-type%3Aiso6523%3A0010%3A%3A5798000000001/services/bdx-docid-qns%3A%3Aurn%3Aoasis%3Anames%3Aspecification%3Aubl%3Aschema%3Axsd%3AInvoice-2%3A%3AInvoice%23%23UBL-2.0

 

and

 

http://smp2.eu/urn%3Aoasis%3Anames%3Atc:ebcore%3Apartyid-type%3Aiso6523%3A0010%3A%3A5798000000001/services/bdx-docid-qns%3A%3Aurn%3Aoasis%3Anames%3Aspecification%3Aubl%3Aschema%3Axsd%3AInvoice-2%3A%3AInvoice%23%23UBL-2.0

3) Section 2.4.4: Change text to:

 

An example is the [ebCorePartyId] specification, which defines a mechanism for referencing participant identification schemes using a formal URN notation.

 

Another example is the Participant Identifier scheme being used in the European PEPPOL network, «iso6523-actorid-upis».

 

4) Section 2.4.5.3: Change text to:

 

Non-normative example using the [ebCorePartyId] URN format, assuming an ISO 6523 International Code Designator 0010 with the participant identifier «5798000000001»:

urn:oasis:names:tc:ebcore:partyid-type:iso6523:0010::5798000000001

In percent encoded form:

urn%3aoasis%3anames%3atc%3aebcore%3apartyid-type%3aiso6523%3a0010%3a%3a5798000000001

 

And the same non-normative example using the PEPPOL Universal Participant Identifier Format:

iso6523-actorid-upis::0010:5798000000001

In percent encoded form:

iso6523-actorid-upis%3a%3a0010%3a5798000000001

 

5) Examples C.1, C.2 and C.3 of Appendix C:

 

Change format of participant identifiers to the attached.

 

6) Change example of Appendix C, section C.4 to:

 

A business with the Participant Identifier «5798000000001» of ISO 6523 ICD 0010 (using the [ebCorePartyId] URN format) would have the following identifier for the ServiceGroup resource:

http://example.org/urn:oasis:names:tc:ebcore:partyid-type:iso6523:0010::5798000000001

After percent encoding:

http://example.org/urn%3Aoasis%3Anames%3Atc:ebcore%3Apartyid-type%3Aiso6523%3A0010%3A%3A5798000000001

[...]

The entire URL reference to a SignedServiceMetadata or Redirect element thus has the form {URL to server}/{identifier scheme}::{id}/services/{document identifier type}::{rootNamespace}::{documentElementLocalName}[##{Subtype identifier}]

The percent-encoded form of the identifier using the above example will then be:

http://example.org/urn%3Aoasis%3Anames%3Atc:ebcore%3Apartyid-type%3Aiso6523%3A0010%3A%3A5798000000001/services/bdx-docid-qns%3A%3Aurn%3Aoasis%3Anames%3Aspecification%3Aubl%3Aschema%3Axsd%3AOrder-2%3A%3AOrder%23%23UBL-2.0

 

Please note that these are all non-normative examples. Nothing in the above invalidates the PEPPOL approach in any way.

 

Best regards,

 

Kenneth

 

Attachment: example-c.1.xml
Description: example-c.1.xml

Attachment: example-c.2.xml
Description: example-c.2.xml

Attachment: example-c.3.xml
Description: example-c.3.xml



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