RE: [xri] Question about update to XSD for XRI Resolution 2.0

["Drummond Reed" <drummond.reed@cordance.net>]

Victor (and all the XML gods):

What I hear Victor saying here is that we should not be declaring any "xrd:"
namespace prefix in the example in the spec (section 3.2). So both the XRDS
element and the XRD element will declare their namespaces "inline" and thus
these will be the default namespaces for their child elements.

I'm making this change in ED 09 unless anyone posts an objection.

=Drummond 

-----Original Message-----
From: Victor Grey [mailto:victor@idcommons.org] 
Sent: Friday, March 10, 2006 12:56 PM
To: xri@lists.oasis-open.org
Subject: Re: [xri] Question about update to XSD for XRI Resolution 2.0

That's a very helpful clarification to something I was still confused  
about Drummond - thanks.
There appears to be one typo though, in the XRD namespace attribute.  
You say:

<XRDS xmlns="xri://$xrds" ref="xri://(example.root)*foo">
<XRD xmlns:xrd="xri://$xrd*($v*2.0)">
	<Query>*foo</Query>
	<Status code="100"/>
	<Expires>2005-05-30T09:30:10Z</Expires>
	<ProviderID>urn:uuid:c9f812f3-6544-4e3c-874e311

This, I think, should either be

<XRDS xmlns="xri://$xrds" ref="xri://(example.root)*foo">
<XRD xmlns="xri://$xrd*($v*2.0)">
	<Query>*foo</Query>
	<Status code="100"/>
	<Expires>2005-05-30T09:30:10Z</Expires>
	<ProviderID>urn:uuid:c9f812f3-6544-4e3c-874e311

or (the imho gratuitously obfuscated):

<XRDS xmlns="xri://$xrds" ref="xri://(example.root)*foo">
<xrd:XRD xmlns:xrd="xri://$xrd*($v*2.0)">
	<xrd:Query>*foo</Query>
	<xrd:Status code="100"/>
	<xrd:Expires>2005-05-30T09:30:10Z</Expires>
	<xrd:ProviderID>urn:uuid:c9f812f3-6544-4e3c-874e311

This typo still exists in the example XRD in ED8 as well.

=vg

On Mar 10, 2006, at 12:14 PM, Drummond Reed wrote:

>> _____________________________________________
>> From: Mohit Raj [mailto:mohit.raj@amsoft.net]
>> Sent: Friday, March 10, 2006 7:45 AM
>> To: Drummond Reed
>> Subject: Changes to XRD and xsd
>>
>> Hi Drummond,
>>
>> 1. It required us following changes to parse the XRDS:
>>
>> a. XRDS element has to be namespace qualified AND
>> b. should contain declaration of XRD element namespace also,
>>
>> Below is an example of the root element of what it is changed to  
>> (additions
> in blue)
>>
>> 	Current: <XRDS xmlns="xri://$xrds" ref="xri://=bar">...</XRDS>
>> 	Changed: <xrds:XRDS xmlns:xrds="xri://$xrds"
> xmlns:xrd="xri://$xrd*($v*2.0)" ref="xri://=bar">...</xrds:XRDS>
>>
>> 2. Priority attribute of elements is not included in the xsd of the  
>> XRD
> given in XRI Resolution spec. Although in reply to an email dated  
> November
> 18, 2005, you had mentioned that we can >assume the priority attribute  
> for
> the elements specified in the resolution spec. So we have added the  
> priority
> attribute ourselves to the xsd. I guess that should be fine?
>>
>> Thanks,
>> Mohit
>
>
> Mohit,
>
> Good timing - the Working Draft just posted
> (http://www.oasis-open.org/committees/download.php/17074/xri- 
> resolution-v2.0
> -wd-10-ed-08.pdf) still did not include an updated schema - that's one  
> of
> the key to-dos for the next (and final) Editor's Draft 09. I was  
> tasked to
> do the first draft of the updated schema, then Gabe is going to check  
> my
> work and the extensibility architecture, and then the other editor's  
> (and
> you) will check his work.
>
> If necessary, the priority attribute will be explicitly added in this
> update, although I believe it is already a global attribute that can  
> be used
> with any element (Gabe, you will want to check this.)
>
> Now, about the namespace issue. Although "by convention" most XML  
> documents
> declare all namespaces in the root element (see
> http://www.zvon.org/xxl/NamespaceTutorial/Output/example4.html).  
> However
> since XRDS is designed to be a "neutral" namespace that can contain  
> elements
> from any other XML namespace, we have been proceeding with the  
> assumption
> that the XRDS element should only need to contain its own namespace
> declaration, and each XRD element needs to do the same for it's  
> namespace
> (see http://www.zvon.org/xxl/NamespaceTutorial/Output/example8.html).  
> That's
> shown in this snippet from the example XRDS document starting on line  
> 305:
>
> <XRDS xmlns="xri://$xrds" ref="xri://(example.root)*foo">
> <XRD xmlns:xrd="xri://$xrd*($v*2.0)">
> 	<Query>*foo</Query>
> 	<Status code="100"/>
> 	<Expires>2005-05-30T09:30:10Z</Expires>
> 	<ProviderID>urn:uuid:c9f812f3-6544-4e3c-874e311
>
> To my knowledge there are three reasons for this:
>
> 1)	The XRDS and XRD namespaces are separate (even in the spec), and an
> XRDS document can include child elements from any XML namespace.
> 2)	Each XRD that may be included in an XRDS may be a different version
> from a different version namespace (i.e., one could be  
> xri://$xrd*($v*2.0)
> and one could be xri://$xrd*($v*3.0). So each XRD should declare its  
> own
> namespace in its own root element.
> 3)	This way it is not necessary for the XRDS or XRD elements to be
> namespace prefixed (nor their children).
>
> However, based on a discussion on the XRI TC call two weeks ago, the  
> truth
> is that all we control in the XRI Resolution spec is the schema and
> namespace assignments. It is XML and XML Namespaces that controls how  
> these
> can be used. So if one implementation returns an XRDS document that  
> declares
> only the xri://$xrds namespace in the root element and another  
> declares both
> the xri://$xrds and xri://$xrd*($v*2.0) namespaces in the root element  
> and
> then uses namespace prefixes in the XRD elements, they are both  
> correct.
> Resolvers simply need to be able to handle standard XML namespace  
> functions.
>
> Does that answer your question? Gabe, do you have anything further to  
> add?
>
> =Drummond
>
> <winmail.dat>---------------------------------------------------------- 
> -----------
> 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