I actually see a benefit to not being able to extend the basic
link building blocks (rel, uri, media type) since the whole point is for
clients to rely solely on the rel. Any extension on these attributes/elements
is likely to impact matching and processing rules.
EHL
From:
[mailto:] On Behalf Of Drummond Reed
Sent: Monday, September 28, 2009 11:11 AM
To: Will Norris
Cc: XRI TC
Subject: Re: [xri] Links as atomic packages of optional attributes
Will, FWIW, my
non-implementor's opinion is the same, which is that keeping them as child
elements keeps the whole design slightly more flexible. Also, +1 to prescribed
order.
Others?
=Drummond
On Mon, Sep 28, 2009 at 10:44 AM, Will Norris <> wrote:
As an implementor, I'll say that reducing the cardinality to
0-or-1 simplifies things enough that attributes vs elements doesn't have much
of an additional impact. I've mentioned my concern that using attributes
reduces the number of extension points for other specs. This could
actually be seen as a good thing for some implementors. And I'm not sure
that we have any real use cases of adding an extension attribute off of a
<Rel> element, for example, (no John, we shouldn't be using Rels to add
metadata-ey information about the linked resource :-P ) but it's at least
something to keep in mind.
The only thing that might make it a little easier when using elements is having
a prescribed order. I think I had actually voted against prescribed
element order some months ago when we made the switch to any order. But
now after implementing it, I'm realizing the strict order would make things a
tad simpler. But like I said before, reducing the cardinality is the
biggest piece, so that even element order is not too much of problem at this
point... it's nothing I'd fight too strongly for if others like the
flexibility.
-will
On Sep 28, 2009, at 10:16 AM, Drummond Reed wrote:
Eran, very good point about the
child elements that are still needed for
trust.
I also like the idea of specifying a choice of either URI or URITemplate in
each linking "atom".
I personally have no strong opinion about whether, for 0-or-1 cardinality,
it is better to use an attribute or a child element. I leave that to the
implementation experts on the list.
Given that we do need to close the attribute-or-element issue, let me turn
it into a question: who DOES have strong feelings about whether the 0-or-1
cardinality items should be an attribute or a child element?
=Drummond
On Sat, Sep 26, 2009 at 7:05 PM, Eran Hammer-Lahav <>wrote:
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:
<Link uri=”” rel=”” mediatype=””>
<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:*
[mailto:]
*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
---------------------------------------------------------------------
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
