[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bdxr] SML / SMP / NAPTR question
Hello Dale,
Yes I think the pattern of matching hierarchies in domain
names to hierarchies in services URLs could be more common.
It would be
useful to specify how this relates to the various DNS profiles, e.g. we would no
longer conform to the "U" subset of NAPTR (if I understand the spec).
Pim
From: Dale Moberg [mailto:dmoberg@axway.com] Sent: 09 April 2013 16:30 To: Pim van der Eijk; bdxr@lists.oasis-open.org Subject: RE: [bdxr] SML / SMP / NAPTR question OK,
if a backreference would work, then we would add to the processing model a
remark that some metadata services may use that regexp
mechanism. Do
you anticipate that any other metadata service would need this additional DDDS
processing for arriving at the service URL? Perhaps these extensions could be
bundled into a fuller elaboration of what the conformance API can
include? Of
course, at present there is no prohibition that prevents metadata services from
extending the bare bones DDDS processing model being
specified. From: Pim van der Eijk
[mailto:pvde@sonnenglanz.net] Hello
Dale, I was
thinking that if the DNS record would have a format <documentId
or hash over documentId>.<hash over
recipientID>.<schemeID>.<SML domain> then a
regular _expression_ that has a backreference to the first part
(<documentId or hash over documentId>) could place the document identifier
string in the URI replacement string and something like the SML/SMP convention
could be used. Then we would not need any REST query syntax but just use
the DNS mechanism. But I'm not sure if these backreferences are allowed in
the constrained type of NAPTR records you suggested we use.
Pim From: Dale Moberg [mailto:dmoberg@axway.com] Comment
and question below. From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org]
On Behalf Of Pim van der Eijk 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]