OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xri message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xri] Links as atomic packages of optional attributes


Yes, that's a good point that the processing rules change if you change the basic selection elements. That's why I'm attracted to a model of extension through new URIs for Rels and Types (or new media types) before adding new extension XML elements.

Bob Morgan suggested to me today that we test the XRD extensibility model by seeing if "common" XRD uses like OpenID and OAuth were going to need any XML extensions to XRD (vs. just their own Rel and Type URIs). It struck me that right now the only XML extension element I am aware that OpenID will need is a LocalID alias for OpenID delegation.

Are there any others?

=Drummond

On Mon, Sep 28, 2009 at 12:02 PM, Eran Hammer-Lahav <eran@hueniverse.com> wrote:

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: drummond.reed@gmail.com [mailto:drummond.reed@gmail.com] 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 <will@willnorris.com> 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 <eran@hueniverse.com>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:* 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

 

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

 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]