atom feed19 messages in org.oasis-open.lists.xriRE: [xri] Aligning XRD with Link (Hea...
FromSent OnAttachments
Eran Hammer-LahavNov 25, 2008 11:59 am 
Breno de MedeirosNov 25, 2008 12:15 pm 
Drummond ReedNov 25, 2008 12:16 pm 
John BradleyNov 25, 2008 12:38 pm 
njo...@ouno.comNov 25, 2008 12:44 pm 
Barnhill, William [USA]Nov 25, 2008 12:54 pm 
John BradleyNov 25, 2008 12:57 pm 
Drummond ReedNov 25, 2008 1:08 pm 
Barnhill, William [USA]Nov 25, 2008 1:28 pm 
Brian EatonNov 25, 2008 1:30 pm 
Breno de MedeirosNov 25, 2008 1:33 pm 
Breno de MedeirosNov 25, 2008 1:44 pm 
John BradleyNov 25, 2008 4:52 pm 
Breno de MedeirosNov 26, 2008 5:07 pm 
Drummond ReedNov 26, 2008 5:56 pm 
Eran Hammer-LahavNov 26, 2008 6:30 pm 
John BradleyNov 26, 2008 7:07 pm 
Drummond ReedNov 26, 2008 8:24 pm 
Chasen, LesDec 2, 2008 8:32 pm 
Subject:RE: [xri] Aligning XRD with Link (Header/Element)
From:Barnhill, William [USA] (barn@bah.com)
Date:Nov 25, 2008 12:54:26 pm
List:org.oasis-open.lists.xri

+1, nice idea. Wouldn't be surprised if we see a lot of possibilities in using
XRD to represent various microformat tags.

On another note... I kept silent before as XRI 2.0 was going to spec approval, but now would like
to run an idea up the flagpole. Everything in XRDS that allowed modification of
the URI was based on appending. From my standpoint that could be improved
greatly if replaced with a substitution method similar to Rails routes. To do
this you would need a minimal set of variable such as QXRI, CURRSEG (auth seg
this XRD is for), AUTH, PATH, QUERY, FRAGID and ideally a path expression
language that let you for instance access the first segment of the AUTH in one
spot and second segment of the AUTH elsewhere. For example let's say <XRD> <Service> <Type>http://example.com/relationship</Type> <MediaType>application/xml</MediaType> <URI>http://example.org/documents/($p$PATH)/($p$CURRSEG).xml</URI> </Service> <Service> <Type>http://example.com/relationship</Type> <MediaType>application/pdf</MediaType> <URI>http://example.org/documents/($p$PATH)/($p$CURRSEG).pdf</URI> </Service> </XRD> The var expressions could use work, definitely, and the usefulness of this if
you are only doing a few files is pretty small. However if you are doing many, or dynamic files, then it seems like it would be
very useful, especially if combined with other XML technologies such as
Xinclude: <XRD xmlns:xi="http://www.w3.org/2001/XInclude"> <xi:include href=http://example.org/fragments/svc_for_pdf_rep" /> <xi:include href=http://example.org/fragments/svc_for_xml_rep" /> </XRD> Note that this could be accomplished server-side only, in which the client need
never see anything other than the XRD in your message, but I can see usefulness
in allowing client to see and process these patterns. Thanks, =Bill.Barnhill

From: Eran Hammer-Lahav Sent: Tue 11/25/2008 2:59 PM To: xr@lists.oasis-open.org Subject: [xri] Aligning XRD with Link (Header/Element)

As currently proposed:

<XRD> <Service> <Type>http://example.com/relationship</Type> <MediaType>application/xml</MediaType> <URI>http://example.org/document</URI> </Service> </XRD>

Is semantically equivalent to:

HTTP Header: Link: <http://example.org/document>; rel="http://example.com/relationship"; type="application/xml";

HTML Element: <Link rel="http://example.com/relationship" href="http://example.org/document" type="application/xml" />

Given that Link(s) are becoming the prominent mechanism for metadata on the web, I think there is great value in lining up XRD with that trend. So...

I would like us to seriously consider renaming:

Service --> Link Type --> Rel MediaType --> (unchanged) URI --> (unchanged)

EHL