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