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: Re: [xri] What is this XRD is for?


On Thu, Feb 4, 2010 at 16:00, Eran Hammer-Lahav <eran@hueniverse.com> wrote:
> Huh?
>
>> -----Original Message-----
>> From: Breno de Medeiros [mailto:breno@google.com]
>> Sent: Thursday, February 04, 2010 3:14 PM
>> To: xri@lists.oasis-open.org
>> Subject: [xri] What is this XRD is for?
>>
>> The XRD is metadata about a resource.
>
> XRD describes a resource. The word metadata is confusing at best.
>
>> Given an XRD document, what is the resource it is about?
>
> If there is a <Subject> it is about the resource *identified* by the URI. If there is no <Subject>, the XRD's subject is defined by other means, outside the scope of the XRD 1.0 spec.

Fine.

>
>> I think we should say in the spec that if no <Subject> is present, then the
>> spec does not define a mechanism to answer that question, though
>> extensions of the spec can provide a means to infer the answer to this
>> question.
>
> " If <Subject> is not specified, it is expected that the resource described by the XRD will be identified by other means."
>
> How is that not enough?
>
>> If a <Subject> is present, then I think we should specify what it means.
>
> Under 2.1:
>
> "Provides the identifier of the resource described by this XRD"
>
> However, under 2.3:
>
> "The <Subject> element contains a URI value which identifies a resource"
>
> I changed the spec to say "The <Subject> element contains a URI value which identifies the resource described by this XRD" to be more consistent. Enough?

I don't think so. This language can mean many things. We should make
it explicitly that identifiers the resource in a scheme-specific
manner.

>
>> <Alias> should be interpreted as 'metadata also for X' where, where 'X' is
>> inferred from the Alias using the same rules for the <Subject>.
>
> Absolutely not. <Alias> is about the resource, not about the XRD. In other words, <Alias> does not extend the scope of an XRD document. <Alias> is for cases when a resource can be identified by more than one URI, but in which URI comparison rules (scheme-specific) would result in different resources.
>
> For example:
>
> http://example.com/joe
> acct://joe@example.com
>
> Can both denote the same resource but one uses HTTP and the other ACCT. If an XRD has the HTTP in the subject, that's all the XRD is about. If that XRD also has the ACCT one in an alias, all it means is that the resource identified by the subject can also be identified by the alias, but it does not mean that the properties and links associated with the HTTP-identified resource apply to the ACCT-identified resource.
>
> An XRD is about a resource, but URIs are not just pointers, they can have their own semantics and internal meaning.

Yes, I just meant here that the concept of <Alias> is identical as
<Subject>, i.e., the rules to find out what resource is mentioned by
an <Alias> element is the same as for a <Subject> element.

>
>> My thoughts currently are that the resource is the equivalence class of URIs
>> in a scheme-dependent way. My thinking is that these URIs are alternative
>> representations of the same resource, and XRDs are meta-data about
>> resources, not about a URI string.
>
> This discussion becomes useless very fast. XRD is about what the URI *identifies*.

"URI identifies" can mean a lot of things to a lot of people. I would
like it to say what the "URI identifiers, in a scheme-specific manner"

>
>> E.g.: http://EXAMPLE.com http://example.com/ http://example.com:/
>> http://example.com:80/ are alternatives for http://example.com.
>
> The trailing '/' isn't automatically equivalent to the one without it. It is only defined in the HTTP protocol, not for the HTTP URI scheme. Just because you serve two different documents at these endpoints (with or without a root /) doesn't mean they identify the same 'resource' outside HTTP protocol.

I'm not proposing that we copy the definitions from other standards,
but unless  the phrase 'scheme-specific' is used, "resource identified
by a URI" is just too vague.

>
> But again, none of this matter. XRD doesn't deal with this - it is all handled by other standards.
>
> EHL
>



-- 
--Breno

+1 (650) 214-1007 desk
+1 (408) 212-0135 (Grand Central)
MTV-41-3 : 383-A
PST (GMT-8) / PDT(GMT-7)


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