the role of FLD in extensions (was Re: one thing we forgot)

...

> Regarding your "it's probably okay to have stratnaf be the first cut" I will
> not comment technically because you obviously did not think this through.

Probably.  I started to think about using rulesets written with one kind
of NAF on a system which implements another kind of NAF, ... and decided
it was more complicated than I wanted to think about right now.

...

> But it must be in FLD and compliance with FLD will have to be
> appropriately specified. This is the next fight :-)
...
> > Vendors can't add this local extension unless FLD licenses it?  That
> > can't be right.
> 
> Yes, this is the purpose of FLD.
> FLD is our best chance at extensibility currently.
...
> > > This would work if you will not insist that such a thing violates some
> > > higher laws and cannot be accepted as a matter of principle.
> > 
> > Heh.  I think the most we can to is give dialect/extension designers
> > good reasons for designing certain kinds of dialects/extensions and hope
> > they are persuaded.
> 
> If they want to be officially sanctioned then they should convince us why a
> particular dialect does not fit in the framework.

This last bit reminds me why I think we don't actually need a fight (and
I why I decided I was okay with the text in FLD at F2F10).  I think
you're trying to serve the extension/dialect designers who want their
product to be a blessed standard.  I think I'm trying to serve the
extension/dialect designers who just want to do their own thing on the
Web, without official blessing, and somehow have it interoperate.  I'm
okay with FLD constraining the first camp, and (realistically,
practically) nothing we do can constrain the second camp.  The second
camp needs social and technical mechanisms for forward and backward
compatibility, to actually get interoperation, but they're probably less
interested in filling into our framework.

      -- Sandro

Received on Sunday, 6 July 2008 03:01:15 UTC