RE: [xri] Aligning XRD with Link (Header/Element)

Bill, at the F2F we discussed a URI templating proposal Eran has been developing (which I just now realized I failed to capture in the minutes – the meeting went so fast it was hard to keep notes). That proposal would replace the functionality of the current append attribute on the URI element.

Eran, do you want to post more details about that?

=Drummond

From: Barnhill, William [USA] [mailto:barnhill_william@bah.com]
Sent: Tuesday, November 25, 2008 12:55 PM
To: Eran Hammer-Lahav; xri@lists.oasis-open.org
Subject: RE: [xri] Aligning XRD with Link (Header/Element)

+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:

<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: xri@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

---------------------------------------------------------------------

To unsubscribe from this mail list, you must leave the OASIS TC that

generates this mail.  Follow this link to all your TCs in OASIS at:

https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

xri message