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


Eran Hammer-Lahav wrote on 2009-07-28:
> The POWDER framework is unacceptable in its richness/complexity (depending
> on your needs).

If it's too rich, then one could profile it down.

> The goals are to:
> 
> 1. Stay consistent with the overall XRD design
> 2. Allow the same trust profile being proposed for <Subject> to apply to
the
> 'set' with minimal extra code
> 3. Stay within the constraints of the host-meta use case which is to
> describe all resources with the same URI scheme and authority

I would add "4. Avoid duplicating existing work", but it's #3 that I'm
speaking to. If the goal is to address that use case, then just address that
use case. I don't know that creating an open extension point that we don't
actually use is consistent with that.

I thought that what you were saying was that if we create an extension
point, we have to do work to make sure that all the matching rules around
trust constraints are clear, and that if you utilize the extension point,
you have to write your own rules for that. That was why I was saying it
seemed contradictory to me to say "we should have an extension point" and
"avoid breaking the proposed trust profile".

I agree with you that whether it's an extension element or attribute is
immaterial. Either way, I think it means writing additional text to make it
clear that the extension point impacts other behavior in the spec.

-- Scott




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