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] subject sets (was: Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-16)



On Jul 28, 2009, at 3:51 PM, Eran Hammer-Lahav wrote:

>
>> -----Original Message-----
>> From: Will Norris [mailto:will@willnorris.com]
>> Sent: Tuesday, July 28, 2009 2:45 PM
>> To: XRI TC
>> Subject: [xri] subject sets (was: Minutes: XRI TC Telecon 2-3PM PT
>> Thursday 2009-07-16)
>>
>> (Let's NOT continue propagating the "Minutes:" subject, please...  
>> it's
>> rather confusing)
>>
>> I'll let the discussion with Scott run its course, but wanted to  
>> chime
>> in with a couple of questions on this proposal:
>>
>> Regarding extensibility, are we intending the "set" attribute of
>> <Subject> be extensible with new values?  I know we are only planning
>> to define one, "beginswith".  If we ARE intending it to be  
>> extensible,
>> should we not use URI based values, so as not to necessitate the
>> creation of a value registry?
>
> Does XML namespace work for attribute values? I rather avoid a  
> registry and avoid a URI value...

is it possible?  sure, you can have QNames as attribute values.  but  
we absolutely don't want to do that... that's one of the things that  
makes XML Canonicalization such a pain in the ass.  Believe me, we  
don't want to go there.


>> Since <Subject> is used both at the XRD level and at the <Link>  
>> level,
>> has any thought been giving to ramifications of having a subject set
>> at the <Link> level?  It might simply not make sense, it might be
>> perfectly valid, I'm not sure.  Just wanted to make sure we thought
>> through that.
>
> It is perfectly valid because you are giving a hint (or requirement,  
> if used for trust) as to what to expect on the other side. Since the  
> other side can have a set, so can a Link. This point seems to favor  
> a single element for simplicity.

fair enough


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