Re: [OpenID] [xri-comment] My Feedback for XRD Vrsion 1.0

[Santosh Rajan <santrajan@gmail.com>]

Hi John,

Well in this thread, I was getting to exactly what you were talking about. The "optionality of the Subject XML".

I have already said that Resource's are "aggregation's of Resources".

Now it so happen's that the argument for "optional Subject" is based on the "supposed fact" that the host-meta cannot have a Subject.

What I have proven here is that the

"host-meta is an aggregation of all the resources available on the same domain (ie Resources that happen to have the same domain as the host-meta in their URI's). So the host-meta is no different from any other XRD which has a <Subject>.

So the host-meta MUST have a <Subject> element like any other XRD.

So there are no more use cases of XRD's that do not require a <Subject> element. 

And hence the <Subject> of an XRD cannot be optional any more. Either it has to be mandatory or at least "RECOMMENDED". 

Now if the Subject is "RECOMMENDED" instead of "MUST" (which is what I want), you still need to provide a "Valid" reason why the Subject cannot be there.

The arguments given by Eran are NOT "valid enough". In fact, at best, he has given some technical mumbo jumbo to support his case, which could hardly be construed as "valid enough" for a "RECOMMENDATION".

On Tue, Nov 10, 2009 at 7:24 PM, John Kemp <john@jkemp.net> wrote:

Hi Santosh,

On Nov 9, 2009, at 10:53 PM, Santosh Rajan wrote:

I think the whole problem is with the definition of the XRD, as I have suggested in the original post.

Well, that might be a problem, but it is not what I have been asking about in this thread. As far as I'm aware, I'm specifically talking about the optionality of the Subject XML element and ways of representing the subject of an XRD document, and I'd prefer that in that thread, we restrict discussion to that topic, just to keep the discussion threads understandable.

Cheers,

- johnk

We need to see the XRD not not as "describing a resource", but as an "aggregator of a set of resources". I will rewrite the definition of an XRD.

"An XRD aggregates a set of related resources into a given Resource".

Note that we are talking of two types of Resource's here.
1) The "given Resource", the one the XRD is describing.
2) The Resource's pointed to by the Link elements. These are Resources which make up the "given Resource".

The important point to note here is that this is an aggregation of "Resource's" NOT aggregation of "Links".

Now if we agree that the host-meta is an aggregation of all Resources with URI's that share the same domain name, then the host-meta defaults to a single Resource identified by a URI. In other word's the host-meta is same as any other XRD.

On Tue, Nov 10, 2009 at 7:20 AM, John Kemp <john@jkemp.net> wrote:
On Nov 9, 2009, at 8:23 PM, John Bradley wrote:

John,

I am having a hard time with your argument that http: URI are not sufficient for naming resources.

I didn't say that.

I simply said that using a string for the base type would make things easier.



I would recommend you read the TAG findings on XRI and XRDS.
http://www.w3.org/2001/tag/doc/URNsAndRegistries-50

I will for the sake of argument agree with Roy Fielding that http: URI can be used as names for any and all resources.   That is distinct from them being used as locators for all resources.

I fail to see a compelling argument for allowing strings in XRD subjects and creating a registry of subject types. (been there it didn't go well)

Please don't take us down that road again.

A XRD Subject, is a NAME it is not a Locator.

I understand, really.


 Constraining Subject to a absolute anyURI is not unreasonable in my opinion.   Subject can name information and non information resources.

It's not necessarily unreasonable to me either, but it does put the host-meta spec. into being forced to deal with URI scheme hell to meet the use-case.



Subject is not always required because it could be specified in some other way by the protocol using the XRD.  Profiles of XRD are free to make it required.

Regardless of how the Subject is specified, it could be referenced in the document too. And if it exists, what is the reason _not_ to link to it in the document?



If a XRD is retrieved via HTTP the protocol retrieving it may choose to infer the subject (Name) is the Locator (URL).

This is an XML doc if someone outside of the XRI-TC thinks they need extension elements to describe the Scope of the XRD that is up to them.  They define a namespace and have at it.

Would it make you happy if host-meta had a subject ie:
<Subject>http:/google.com/#host-metta</Subject>

as well as the <hm:Host> elements to describe scope for the templates.

Even if <Subject is not used for anything in the host-meta spec?

Given the history you will not convince the XRI-TC to define Subject to be something other than a URI.

Yes, that seems apparent. And it seems that host-meta will not get into the URI scheme hot water. I can't say I blame either group.

Regardless of my opinion, it seems that if neither side will change their collective minds, we're left with the status quo, and we'll have to settle on it as the least-bad alternative.

- johnk


 That we didn't restrict it to http: URI will probably get us into hot water in some places.


Regards
John Bradley


On 2009-11-09, at 8:35 PM, Eran Hammer-Lahav wrote:



-----Original Message-----
From: John Kemp [mailto:john@jkemp.net]
Sent: Monday, November 09, 2009 2:14 PM

I believe that an XRD always has a subject. So far, I have seen no
argument to the contrary, and the use-cases discussed all seem to have
a subject, even when it is called host.

We agree on that. The question is only whether it is useful to define an element generic enough to support the wide range of potential subjects and still enable interoperability.

I do see a pragmatic issue about how the subject of an XRD is
represented in the XRD document itself.

What I am trying to convey is that from my perspective, the use case supported by the current <Subject> design is by far more likely than any other use case, and is the primary driver in developing XRD. I am reluctant to design an element without better requirements or use cases.

I agree that this issue is tough to solve, but I think providing
common subject-related semantics at the XRD level with a measure of
extensibility in the right direction is simply good design.

I think that's what we have done. We just don't agree on how this extensibility should be provided.

I don't have any particular investment in XRD at all, so you are
certainly free to evaluate (hopefully without further unwarranted
ridicule) my arguments and decide not to pursue any changes.

If anything I wrote came off as ridiculing your views please accept my apology. I have meant no disrespect. My request for use cases wasn't made as criticism, but an actual request for use cases.

- johnk

_______________________________________________
general mailing list
general@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general


_______________________________________________
general mailing list
general@lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-general



--
http://hi.im/santosh

--
http://hi.im/santosh