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] SML / SMP / NAPTR question


Comment and question below.

 

From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Pim van der Eijk
Sent: Monday, April 08, 2013 7:30 AM
To: bdxr@lists.oasis-open.org
Subject: [bdxr] SML / SMP / NAPTR question

 

I'm prototyping some BDX and other technologies and ran into the following issue:

 

In SML, one URI pattern is defined, to be used when a retrieving metadata for a specific document type:

 

http://<hash over recipientID>.<schemeID>.<SML domain>/<recipientID>/services/<documentType>

 

Section 2.2 of the PEPPOL SMP suggests SML/SMP also provide an interface to retrieve a ServiceGroup for a given Participant Identifier.  In this case we don't know the document type.  What is the URI pattern to use to retrieve a ServiceGroup and where in SML or in SMP is it defined ?

 

When using NAPTR "U" records, the second occurrence of "recipientID" in the URI would no longer needed as the record can directly reference a recipient-specific resource on the metadata server, it is not just a domain.  That is an improvement.  But that raises the question how to combine that referenced resource identifier with a variable documentType.  Can the regular _expression_ be used? 

 

So far, the backwards compatibility in DDDS approach was only for a “constant path”  such as  “/<recipientID>/services/” If variation over documentTypes were defined, I think we would need to either augment the NAPTR DDDS processing model or just let that be an additional “query” language for a given metadata service type (like SMP, for example) CPPA does not have any query notation defined (except perhaps queries available from RegRep)  I had raised the issue of query languages for metadata services (for finer granularity of access to information) but until now, no one had expressed much interest in doing that. It seems to me to belong to the metadata service side of standardization responsibility, rather than DDDS processing model. But that is just my working division of labor. There are now a lot of different REST query notations being proposed (like the one in OASIS OData). I don’t know if that would just be a distraction or not. I am not certain how a regexp would help out here. It would have to take elements from http://<hash over recipientID>.<schemeID>.<SML domain> and compute a document type. Not sure that would be feasible. Or do you have something else in mind, Pim?

 

 

 

The  "/services/" substring in the URI seems to be unnecessary in SML already.

 

 

 

 

 

 

 

 



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