OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

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


Subject: Addition of Resolution Issue #15: URI Scheme Attribute


Per the earlier emails on this thread, I have added "Resolution Issue #15:
URI Scheme Attribute" to the Resolution change management page at:

	http://wiki.oasis-open.org/xri/Xri2Cd02/ResolutionChanges

This issue has been assigned to Victor Grey. The requirements/proposal page
for this issue has been posted at:

http://wiki.oasis-open.org/xri/Xri2Cd02/ReSolution/I15UriSchemeAttribute

Please look this over and continue discussion on the list.

=Drummond 


-----Original Message-----
From: Drummond Reed [mailto:drummond.reed@cordance.net] 
Sent: Thursday, September 15, 2005 9:43 PM
To: 'Victor Grey'; xri@lists.oasis-open.org
Subject: RE: [xri] Comment on XRI Resolution working draft 9

[Again, for anyone reading this message, Resolution Working Draft 9 has not
been posted yet. Victor's message refers to a draft still in editing.
However his comments apply fully to the current Committee Draft 01.]

Following is a first parsing for the info we need to put it this proposal
from Victor through our change management process. Again, please post any
feedback. Unless there are objections, after tomorrow's TC call I will post
it to the wiki as a Resolution issue/change proposal.

=Drummond 

RESOLUTION ISSUE/CHANGE PROPOSAL

INTRODUCTION/MOTIVATION

Resolve two potential bugs: multiple conflicting version numbers and
multiple conflicting ID elements on XRIDescriptor elements.

REQUIREMENTS

 * Make it clear how proxy resolvers and other clients who must aggregregate
multiple XRIDS should handle different version numbers, and also what the
version number of the enclosing XRIDescriptors element should be.
 * Ensure that there is no conflict between ID elements which must be unique
in an XML document even when collated from multiple resolution servers by a
proxy resolver or other client.
 * Simplify if possible the processing burden for a client.

PROPOSAL

Tentative proposal on the versioning issue:

 * Specify versioning only at the XRIDescriptor level and not have
versioning at the XRIDescriptors level, so each XRIDescriptor is
self-describing. (Note that the XRIDescriptors element COULD have a separate
version number that has no relationship to its contained XRIDescriptors
version numbers, but this seems overkill given that it is only a pure
wrapper element.)

Tentative proposal on the ID attribute issue:

 * Use the value of what is currently the AuthorityID element (since it is
already required to be unique).


-----Original Message-----
From: Victor Grey [mailto:victor@idcommons.org] 
Sent: Thursday, September 15, 2005 5:29 PM
To: xri@lists.oasis-open.org
Subject: [xri] Comment on XRI Resolution working draft 9

As described in working draft 9, when you query the authority for the 
first sub-segment of an XRI, you
get back an XML doc like so:
<XRIDescriptors xmlns='xri://$res*schema/XRIDescriptor*($v%2F2.0)'>
<XRIDescriptor>
......
</XRIDescriptor>
</XRIDescriptors>

The next sub-segment, let's say it's at a different authority server,
delivers a similar document:
<XRIDescriptors xmlns='xri://$res*schema/XRIDescriptor*($v%2F2.1)'>
<XRIDescriptor>
......
</XRIDescriptor>
</XRIDescriptors>

The final XML document that the resolver client returns must, it seems
to me, extract all the </XRIDescriptor>...</XRIDescriptor> elements,
and include them in -one- <XRIDescriptors> element, because there should
be one root element in an XML document. But if, as in my example,
the different XRIAuthorities return different <XRIDescriptors>
versions, which is entirely possible since the upstream authority has
no knowledge of what's being served downstream -- what version number
to use on the final result returned by the resolver client?

A solution would be to remove the version
attribute from the <XRIDescriptors> element and give it to the 
<XRIDescriptor>
element. That way, each <XRIDescriptor> in the chain could have it's own
version, which reflects the reality that the content of each 
<XRIDescriptor>
has to be understood within its own version context.

Another related point is that the <XRIDescriptor> is now described in 
wd9 as having an xrdi:id attribute. Because the resolver is 
accumulating XRIDs from a chain of servers, the XRI Authority server 
must return an xrdi:id attribute that is globally unique. OTOH, since 
the <XRIDescriptors> element is an -ordered- collection of 
<XRIDescriptor> elements, is there really any need for the xrdi:id 
attribute?

=vg


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



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




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