[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]