[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [bdxr-comment] Suggestions for SMP 2.0
Hi Philip Great suggestions, and as always your comments are highly appreciated. I’ve made a note of your email so we will be sure to include them when we start working on SMP 2.0! Best regards, Kenneth On 11/29/16, 5:36 AM, "bdxr-comment@lists.oasis-open.org on behalf of philip@helger.com" <bdxr-comment@lists.oasis-open.org on behalf of philip@helger.com> wrote: Dear all! I have some thoughts on SMP 2.0 specification that I want to bring forward to you. Please find attached a "draft" document that is based on CS 03 and uses track changes mode. The basic things that are currently not ideal from my point of view are the following (this is a summary of changes): * I would remove the ServiceEndpointList and ProcessList elements, as they are just bloating the created XML - removing them harms nobody * Please change "Document Identifier" to "Document Type Identifier" as it identifies a document type and not a document (instance) * I would prefer, if the ServiceMetadataReference would not contain the full target URL with participant and document type, but only the document type. The final URL can easily be build by SMP clients and it would be much easier to achieve this. Especially if an SMP is running behind a proxy, the SMP must always know it's "public URL" to be used in this element. This leads to problems in production, if e.g. the URLs between the ServiceGroup query and the contained ServiceMetadataReference are different (seen this quite often!) * For the "Redirect" element I also suggest to only put the hostname of the target SMP there. Since the target SMP must follow the same specification as the source SMP, it would be quite easy to build the URL in the SMP client. Additionally it avoids problems with URL differences (see above). * I suggest an additional constraint if ServiceActivationDate and ServiceExpirationDate are both present * I suggest some additional information on scheme identifiers (chapter 2.4.4) * I suggest an additional example for a participant identifier without a scheme (chapter 2.4.5.3) * I suggest to use the MIME type application/xml instead of text/xml based on RFC 3023 (chapter 3.2.1) I hope you find this input valuable. BR, Philip
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]