RE: [ebxml-msg] Draft wording for resolution of subchannel MPC discussion, April 22 action item done.

["Jacques R. Durand" <JDurand@us.fujitsu.com>]

Looking at it from a different angle:
I understand we do not want to be too specific of which hierarchical scheme is to be used.
Yet we could define the most basic common rules that we want users to build on, so that at least we don't have random URIs picked for sub-channels. From there we let users choose something intuitive enough.

Can't we say something like:

"MPCs are URIs. Different ways to indicate hierarchy in URIs exist, that can be used to indicate a channel / subchannel relation. When the MPC (y) is a sub-channel of another MPC (x), the following rules apply:
- the scheme in (x)(y) must be same (and the authority if used in one must also be used in the other with same value)
- the path of the URI of the sub-channel (y) must start with the path of of the URI of the parent channel (x)."

So these are valid pairs:

Channel: foo://example.com:8042/over?name=ferret
Subchannel: foo://example.com:8042/over/there?name=ferret

Channel: urn:example:animal:ferret
Subchannel: urn:example:animal:ferret:nose

Channel: urn:example:animal:ferret:nose.xxx
Subchannel: urn:example:animal:ferret:nose.xxx.zzz
(note: reverse pair also OK, although user unlikely to make this choice)

Channel: foo://example.com:8042/over/there
Subchannel: foo://example.com:8042/over/there?name=ferret
(note: reverse pair also OK, although user unlikely to make this choice)

Channel: foo://example.com:8042/over/there?name=ferret
Subchannel: foo://example.com:8042/over/there?name=ferret#nose
(note: reverse pair also OK, although user unlikely to make this choice)

Channel: foo://example.com:8042/over/there?name=ferret#head
Subchannel: foo://example.com:8042/over/there?name=ferret#nose
(note: reverse pair also OK, although user unlikely to make this choice)


Jacques

-----Original Message-----
From: Moberg Dale [mailto:dmoberg@axway.com]
Sent: Thursday, April 23, 2009 3:37 PM
To: ebxml-msg@lists.oasis-open.org
Subject: [ebxml-msg] Draft wording for resolution of subchannel MPC discussion, April 22 action item done.


ebXML MPC identifiers can be used to implement a wide variety of channel filtering regimes. MPCs are URIs. Because certain URI schemes support "hierarchy" by using the "/" character to separate path segments (such as the "HTTP" scheme), paths may be used to group related channels into channels and subchannels. Although each URI remains a distinct MPC, local conventions may use channels and subchannels to simulate channel filtering of either hierarchical topics (where subchannels are topic
specializations) or to simulate fixed, content-based filters. [Query parameters, if supplied, have semantics defined by implementations, and not by this specification. The semantics of paths in simulating topics or content-based filters is not defined by this specification, but would need to be defined by implementations or bilateral participant agreements. -- optional]



[I think I mentioned on the call that either HTTP URLs or URNs could be used to simulate MPC subchannels. But I glanced back at http://www.ietf.org/rfc/rfc3986.txt  (Uniform Resource Identifier (URI):
Generic Syntax ) and realized that "/" is normally given the role of indicating hierarchy in a path. And though URNs look like a structured identifier with hierarchy, I cannot find anywhere that indicates that the ":" in a URN actually indicate path segments.

The following are two example URIs and their component parts:

         foo://example.com:8042/over/there?name=ferret#nose
         \_/   \______________/\_________/ \_________/ \__/
          |           |            |            |        |
       scheme     authority       path        query   fragment
          |   _____________________|__
         / \ /                        \
         urn:example:animal:ferret:nose

And,

A path consists of a sequence of path segments separated by a slash
   ("/") character.  A path is always defined for a URI, though the
   defined path may be empty (zero length).  Use of the slash character
   to indicate hierarchy is only required when a URI will be used as the
   context for relative references.

I am assuming that URNs can in principle,then, have paths that use a ":"
to indicate hierarchy because URNs will not be used as a context for relative references. But the semantics of the path following the urn:nid:xxxxx.yyyy.zzzz is up to the namespace registrar, it seems.
Anyway you can consult http://tools.ietf.org/rfc/rfc3406.txt on URN best practices to follow the story.

It therefore seems to me that we should just omit discussing URNs for MPC identification because it just gets to have a lot of complexity and administrative overhead (useful idea dies by overly intricate
specification...) So I omitted URNs from discussion in the draft above.]


---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php