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


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



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