[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Proposed XRD schema
ResourceType replaces (Service-level) Type, and demoted to a
hint instead of authoritative information. Rel is new and is authoritative. SubjectType is new and is authoritative. ResourceType and SubjectType will use the same type values. Rel can use the same type values but it has a different meaning
(basically add a “my” before, as in “my openid provider”). So on your blog page you can have: <XRD> <Link> <Rel>http://specs.openid.net/relation/provider</Rel> <URI>…</URI> <ResourceType>http://specs.openid.net/auth/2.0/server</ResourceType> <ResourceType>some
openid extensions</ResourceType> And on the openid provider (pointed to by the URI above) you can
have: <XRD> <SubjectType>http://specs.openid.net/auth/2.0/server</
SubjectType > <SubjectType>some
openid extensions</ SubjectType > So the Rel just tells you it is a provider (not which version or
other features). The rest in the first XRD are hints. EHL From: John Bradley
[mailto:jbradley@mac.com] Eran, So I take it that you are thinking that Rel is the
replacement for Type. That an application searches for one or more Rel links in
some application specific order. Are you imagining that an App like openID would have
two relationship types one for a service provider and one for the service
itself? I would like to go through some example resolution flows
before coming to a conclusion on the schema. =jbradley On 17-Feb-09, at 12:41 PM, Eran Hammer-Lahav wrote:
As I previously wrote (re: both Rel and ResourceType): The idea was to preserve the functionality offered by Service/Type
but to redefine it as a hint (in the same sense that MediaType is now a hint
per link semantics). So that the same way to can give a parser a hint that the
URI linked to will serve a JPEG, you can hint that the OpenID provider will
support PAPE. As we know, there are cases where we will trust hints, allowing
us to be more efficient. EHL From: John
Bradley [mailto:jbradley@mac.com] Dirk,ers on the I am also -1 to the idea of
encoding parameters in the Subject type. My example of <Rel>http://Subject
tysome.URI.that.indicates.relationsip.is.self.or.sub.service.com</Rel>- Was just a example of one way of
doing it if we don't want to make SubjectType extensible. When the Meta Data is part of a
Link statement it is clear that it is part of the Link however in the case of
the final XRD (the one with the API URI as the subject. It is less clear
where that goes. If we are describing an optional
part of an API then it is something that the API URI has a relationship with
arguably and could be described in a Link. I don't know if it should.
That depends on what sort of entity model we are creating for these
related XRD. I am still not clear on
the difference between ResourceType and Rel. I suspect one may need to go,
because I suspect that they are probably the same thing in Eran's mind. If we are going to keep both, I
think one needs to be a hint about the type of XRD that the URI is pointing at,
if the URI is discoverable at all. I think there are four of these
sort of relationships: 1 The subject is a individual
(pointing at someone's blog XRD) 2 The subject is a Service
Provider (The XRD will contain multiple Rel types) 3 The subject is a Service (OpenID
as an example) 4 The Subject is a API endpoint
and this is the end of discovery Perhaps there is a relationship
between this and the Subject-Type of the target XRD? I am unclear on what the XRD of a
Service provider would have as it's Subject type? Are people thinking that
it would have multiple SubjectTypes one for each service it provides. Then have Links to the individual
services like OpenID 2.0. I understand that a large part of
discovery will be application specific. More than in XRI 2.0 at least. However I think we do need to
define a common entity model so that applications can have a common view of
what the XRD are describing. =jbradley On 17-Feb-09, at 4:14 AM, Dirk
Balfanz wrote:
On Sun, Feb 15, 2009 at 11:08 PM,
Brian Eaton <beaton@google.com>
wrote: On Fri, Feb 13, 2009 at 7:28 PM,
<njones@ouno.com> wrote: Libraries would wander through the
XML looking for the appropriate
I agree that works inside Link
elements, where the URI is tucked away neatly inside the Rel element, and thus
separated from other potential metadata. But inside the SubjectType, it doesn't
seem to work as nicely. It would look something like this: <SubjectType> <height>500px</height> <width>450px</width> </SubjectType> Is that the same as this: <SubjectType> <height>500px</height> <width>450px</width> th/2.0/ux/popup </SubjectType> ? That doesn't seem right... +1 on using XML parsers, though,
and -1 on funny business with query parameters. Dunno how I feel about
this <Rel>http://some.URI.that.indicates.relationsip.is.self.or.sub.service.com</Rel>-stuff,
though. What's the purpose of that? That's what the XRD top-level section is
for, right? Dirk.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]