[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Proposed XRD schema
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]