Hi, I've had to look at the SMP spec and schema last week, and have a few more comments. 1) The ebCore Party Identifier format is defined in section 2.7 of [PARTYIDTYPE] and has the pattern urn:oasis:tc:ebcore:partyid-type:catalog-identifier:scheme-incatalog:scheme-specific-identifier i.e. the scheme-incatalog and scheme-specific-identifier are separated by a single colon. Section 2.4.5.3 of the SMP specification has example party identifiers in ebCore Party ID and PEPPOL UPIS format. The non-normative ebCore Party ID example given, urn:oasis:names:tc:ebcore:partyid-type:iso6523:0010::5798000000001 , is incorrect, it has two colons. 2) Another comment on that example is that it is claimed that the UPIS and ebCore identifiers are the same non-normative example . But the PEPPOL code 0010 , for GS1 Global Location Numbers, is not the same as the ISO 6523 code 0010 . In ISO 6523, code “0010” is not a code for GLN identifiers but for “Organizational Identifiers for Structured Names under ISO 9541 Part 2” from the “Association for Font Information Interchange: AFII”. The ISO 6523 code value for GLNs is “0088”. 3) The specification has a normative reference to XML Signature 1.1 (2013), but the SMP scheme imports the schema of XML Signature 1.0 (2001). A valid driver for XML Signature 1.1 is included in ebCore Agreement Update
http://docs.oasis-open.org/ebcore/ebcore-au/v1.0/cs01/schema/xmldsig1-schema.xsd . (The schema driver at the W3C site is actually not valid). 4) There are RecipientIdentifier and SenderIdentifier elements in the SMP schema that are not defined in the specification. They are also not used in any of the defined content models in the schema, i.e. the cannot occur anywhere at any level in a ServiceGroup or (Signed) ServiceMetadata. Kind Regards, Pim