RE: [xri] Links as atomic packages of optional attributes

On the cardinality issue, I am in favor of having:

0 or 1 Rel

0 or 1 MediaType

0 or 1 of either URI or URITempate

I don’t think we should separate it to two different link types for URI and URITemplate.

As for expressing link as an attribute, keep in mind that we still have to support Link child elements for at least the trust element. Which means:

<ds:KeyInfo />

</Link>

I am not sure how much we gain from that and if this is any less confusing than just keeping it all as element (with the new cardinality).

EHL

From: drummond.reed@gmail.com [mailto:drummond.reed@gmail.com] On Behalf Of Drummond Reed
Sent: Saturday, September 26, 2009 11:11 AM
To: XRI TC
Subject: [xri] Links as atomic packages of optional attributes

I had another discussion with John Bradley about Breno’s proposal to move to “atomic” links (where both Rel and URI are zero-or-one cardinality). I agree with the point he was trying to make at the end of Thursday’s call about how helpful it would be to XRD crawlers to know what kind of metadata (if any) was at the other end of a link. But when he and I talked about it we both realized that the MediaType element could be used to convey that information.

Of course that’s yet another element that could be reduced to zero-or-one cardinality to keep Links as atomic packages. And of course if it’s zero-or-one cardinality, then it too should can an attribute.

So both John and I found ourselves liking the design of every Link consisting of three optional attributes: Rel, URI, and MediaType, as it would be very clear and easy to process, query, and crawl.

Do others agree?

If so, what happens to URITemplate? Is it a fourth optional attribute? Or are should we have two kinds of links: Link (with optional attributes Rel, URI, and MediaType) and LinkTemplate (with optional attributes Rel, URITemplate, and MediaType)?

=Drummond

xri message