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

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:]
Sent: Thursday, 
April 23, 2009 3:37 PM
To: 
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