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: Question about update to XSD for XRI Resolution 2.0


>_____________________________________________
>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 

<<attachment: winmail.dat>>



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