Hehe Peter, another worm out of the XRD can. Why does XRD 1.0 need to define a xml:id for XRD, given that it is the root element of the XRD, there can only be one?<div>ROTFL if anyone has forgotten this acronym, it is "Rolling ON The Floor Laughing".<br>
<br><div class="gmail_quote">On Sun, Nov 1, 2009 at 3:15 AM, Peter Williams <span dir="ltr"><<a href="mailto:home_pw@msn.com">home_pw@msn.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
Im tempted to say that the xml:id they used (in the abandoned initiative) a<br>
relic of the days when folks were still thinking about simplifing a sequence<br>
of XRDs, and the file recovered might need the locator to point out a<br>
particular one of several i the file (by denoting the xml:id on the XRD<br>
level element.)<br>
<br>
Be interesting to see if LRDD or webfinger has a non HTTP locator concept<br>
(based on that kind of xpointer-like URI). presumably it would only point to<br>
such as a "see also other XRD" location, rather than point out a sub-element<br>
(such as a particular link). This could retain from the XRI days something<br>
of what used to be attached to the old ref (vs redirect) signal - and be<br>
used to the same management/authority transfer issues.<br>
<div><div></div><div class="h5"><br>
<br>
<br>
Peter Williams wrote:<br>
><br>
> I compared the work product you referenced with<br>
> <a href="http://xrds-simple.net/core/1.0/" target="_blank">http://xrds-simple.net/core/1.0/</a> (an abandoned work).<br>
><br>
> Just note the sheer difference in writing style! While staying within the<br>
> scope of the IETF work item, the I-D will ideally go back to the mixed<br>
> description/specification style of the pro-genitor work.<br>
><br>
> Once one becomes a formal WG chair, it's tempting to be so concise and<br>
> embue such logical correctness into English terms while specification<br>
> writing that it ends up sounding like one of those immortal OSI standards<br>
> from CCITT/ISO - written in a technical language that only 3 people in the<br>
> world could speak natively. And they all sat on the committee.<br>
><br>
> The earlier work I cited does address an issue I dont understand - once<br>
> cast into current XRD 1.0 and host-meta terms. See<br>
> <a href="http://xrds-simple.net/core/1.0/#go_fetch" target="_blank">http://xrds-simple.net/core/1.0/#go_fetch</a> (last paragraph). The topic is<br>
> refering to elements of an XRD, given the locator url and its fragments.<br>
><br>
> The problem I had initially with your criticism, if you recall, had<br>
> ignorant ol' me focussing on the XRD.Link.Subject (vs XRD.Subject). I<br>
> wanted the URI (with fragment) to refer to a particular link element, in<br>
> order that the metadata in the link acted as descriptor for that (naming)<br>
> URI. This seemed to align XRD and openid identifiers with semweb. This<br>
> would allow us all to observe only 1 religion about names and addresses.<br>
><br>
> In the abandoned work, fragments on (I think) "returned" locators in such<br>
> as the HTTP Response X-XRDS-Locator URI (or a meta's http-equiv content<br>
> value) could have fragments, which might have pointed to a particular<br>
> element link within the XRD, once retrieved. The fragments had seemingly<br>
> special relationship to the xml:id value (an XML construct) on the link<br>
> element rather than the link.subject (an XRD construct) in the link<br>
> markup.<br>
><br>
> For my part, I now struggle on that topic with the current proposal: what<br>
> concepts got dropped or recast in new form? Things start to swirl.<br>
><br>
> Was the XRDS-Locator different to a 301, 302 or 303, in some subtle way?<br>
> Was there some inner subtlety about using xml:id (given its relationship<br>
> to DOM3 trees)? Was there a hookup with issues of xml dsig signing (and<br>
> its default resolvers)? Did the whole issue just disappear? if so, why and<br>
> what cost?<br>
><br>
> Some of this context is what the IETF I-D needs to bring back, rather than<br>
> be so parsimonious and doctrinal about domains are XRi-like authorities,<br>
> authorities in URI schemes are an embodiment of XRI-like authorities,<br>
> domains and domain-names have a mystical relationships to authority<br>
> fields scheme (and thence to the authorites governing an RDF graph<br>
> node)..... cocnepts that only the higher initiates in the identity gang<br>
> can comprehend.<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> <a href="http://xrds-simple.net/core/1.0/" target="_blank">http://xrds-simple.net/core/1.0/</a><br>
><br>
><br>
><br>
><br>
><br>
> Santosh Rajan wrote:<br>
>><br>
>> <a href="http://www.ietf.org/id/draft-hammer-hostmeta-01.txt" target="_blank">http://www.ietf.org/id/draft-hammer-hostmeta-01.txt</a><br>
>><br>
>> If you have read the spec above, you will wonder where did the "acct:"<br>
>> scheme come from. It came from webfinger. The host-meta spec has been<br>
>> work in progress for a while now. Its predecessor was the "site-meta"<br>
>> spec. The idea of webfinger came later, in may 2009,and the idea of<br>
>> "acct:" about two months back. Given that webfinger is to follow<br>
>> host-meta, the question is "How come host-meta is following<br>
>> webfinger?".<br>
>><br>
>> Think about it. There is an obvious attempt to legitimize the "acct:"<br>
>> scheme here. That is not a bad idea. I like it actually. Consider<br>
>> this. If I type "<a href="mailto:acct%3Asantrajan@gmail.com">acct:santrajan@gmail.com</a><br>
>> <<a href="mailto:acct%253Asantrajan@gmail.com">acct%3Asantrajan@gmail.com</a>>" into my browser location bar, my browser<br>
>> would retrieve my XRD. Now this is an extreme example. But I hope you<br>
>> get the idea. If not please ask me.<br>
>><br>
>> Unfortunately I have a problem with this idea, even though I like it,<br>
>> this is not the way to do it. The problem is that if you want to<br>
>> legitimize "acct:" you need to be a software engineer contortionist.<br>
>> You need to "Reject" Subject from the host-meta, and you need to add<br>
>> "Scope" into the host-meta.<br>
>><br>
>> My contention is that if you really want to this, (and I like the<br>
>> idea), let us get all the DNS, w3c folk on board and do it. Doing it<br>
>> via the "backdoor" is going to cause more harm to the "identity<br>
>> movement" than good.<br>
>><br>
>><br>
>> --<br>
>> <a href="http://hi.im/santosh" target="_blank">http://hi.im/santosh</a><br>
>><br>
>> _______________________________________________<br>
>> general mailing list<br>
>> <a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
>> <a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
>><br>
>><br>
>> -----<br>
>><br>
>> Santosh Rajan<br>
>> <a href="http://santrajan.blogspot.com" target="_blank">http://santrajan.blogspot.com</a><br>
>><br>
><br>
><br>
<br>
--<br>
</div></div>View this message in context: <a href="http://old.nabble.com/host-meta-and-%22acct%3A%22-tp26079872p26146197.html" target="_blank">http://old.nabble.com/host-meta-and-%22acct%3A%22-tp26079872p26146197.html</a><br>
<div><div></div><div class="h5">Sent from the OpenID - General mailing list archive at Nabble.com.<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@lists.openid.net">general@lists.openid.net</a><br>
<a href="http://lists.openid.net/mailman/listinfo/openid-general" target="_blank">http://lists.openid.net/mailman/listinfo/openid-general</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br><a href="http://hi.im/santosh">http://hi.im/santosh</a><br><br><br>
</div>