[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Order of child Service elements from Neustar GRS not right
+1. I’ll be happy to look over the RelaxNG
again when you post it (and update the XSD to match at closely as I can). =Drummond From: Gabe Wachob
[mailto:gabe.wachob@amsoft.net] I’ve done a brief survey of openid
implementations out there and they all seem to parse XRD documents basically
without regard to ordering of elements where it doesn’t matter, so this
“bug” on the part of the GRS is not really breaking anything. What it does break is the verification of
the new RelaxNG schema on XRDs out in the wild since they are all (well, all
the ones generated by XRI resolution at the GRS) broken w/r/t ordering. I do note that the XRDs I have found (very
rare, actually) out there (like from myopenid.net) that result from non-XRI
YADIS-style resolution seem to be correct (I’ve checked myopenid.com)
w/r/t ordering, but then again, they aren’t using that many elements to
begin with (and there’s this opend:Delegate element in there too?) Anyhoo – I think we should just lean
on Les to fix the GRS ASAP and move ahead with the RelaxNG spec with the same
ordering as the WXS (to the extent we are talking about the same elements). PLEASE look at the RelaxNG I’ve
posted and see if the ordering makes sense to everyone. I’ll be posting a
new version soon with a slew of fixes.
-Gabe From: Drummond Reed
[mailto:drummond.reed@cordance.net] Ah, Gabe, I see, you’re talking
about order of elements with the Service element. The order under the XRD
element looks correct. I agree that ProviderID should be the first
child under the Service element. But in any case, what’s served up by the
GRS should match the spec, so let’s figure out how to get it all lined up
in this Committee Draft. Les, what are your thoughts? =Drummond From: Here’s the XRD I was referring to
(retrieved using wget 'http://xri.net/=gmw?_xrd_r=application/xrd%2Bxml%3Bsep=false') <?xml
version="1.0" encoding="UTF-8"?> <XRD
xmlns="xri://$xrd*($v*2.0)"> <Query>*gmw</Query> <Status
code="100"/> <Expires>2007-10-26T04:07:00.000Z</Expires> <ProviderID>xri://=</ProviderID> <LocalID
priority="10">!5F54.52A4.C55A.5E23</LocalID> <CanonicalID
>=!5F54.52A4.C55A.5E23</CanonicalID> <Service
priority="10"> <Type
select="true">xri://+i-service*(+forwarding)*($v*1.0)</Type> <Type
match="null"/>
<ProviderID/> <Path
match="default"/> <Path
select="true">(+index)</Path> <URI append="qxri"
priority="1">http://2idi.com/forwarding/</URI> </Service> <Service
priority="10"> <Type
select="true">http://openid.net/signon/1.0</Type>
<ProviderID/> <URI append="qxri"
priority="2">http://2idi.com/openid/</URI> <URI
append="qxri"
priority="1">https://2idi.com/openid/</URI> </Service> <Service
priority="10"> <Type
select="true">xri://+i-service*(+contact)*($v*1.0)</Type> <Type
match="default"/>
<ProviderID/> <Path
select="true">(+contact)</Path> <Path match="null"/> <URI
append="qxri"
priority="1">http://2idi.com/contact/</URI> </Service> </XRD> From: It appears that the current GRS is not producing correct
XRDs. TO wit, the following XML produced by the GRS has the
ProviderID AFTER the Type element. However, the XSD schema in the document has the
ProviderID as the very first element. The text in the spec is otherwise
ambiguous since the ProviderID is defined in a separate section from the other
Service child elements. I don’t know what the correct ordering is supposed to
be – the on implement by the Neustar code or the one in the XSD, or some
other one? Need to know this for the RelaxNG schema.
-Gabe |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]