RE: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-16

[Eran Hammer-Lahav <eran@hueniverse.com>]

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> Sent: Tuesday, July 28, 2009 10:34 AM
> To: Eran Hammer-Lahav; xri@lists.oasis-open.org
> 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.

Not worth it in this case. It will take more work to profile it than create something new. Same goes for code reuse. And a normative reference to POWDER is a spec suicide for XRD given the current stakeholders. This is not a dig against POWDER.

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

There is nothing I have seen that makes sense to reuse even with profiling.

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

And that additional text, given the current proposal is "same as Subject".

EHL