W3C home > Mailing lists > Public > public-rif-wg@w3.org > July 2008

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

From: Michael Kifer <kifer@cs.sunysb.edu>
Date: Mon, 7 Jul 2008 14:41:58 -0400
To: Chris Welty <cawelty@gmail.com>
Cc: RIF WG <public-rif-wg@w3.org>
Message-ID: <20080707144158.58a71807@kiferserv>

On Mon, 07 Jul 2008 08:36:28 -0400
Chris Welty <cawelty@gmail.com> wrote:

> I don't think this is resolved sufficiently to decide.  We can discuss it 
> further in the upcoming months, in particular as we move our focus to FLD and 
> how it gets instantiated. 

We are not deciding anything now. It is an important matter for FLD, and I just
put in a strawman (in FLD), which was a 5min work. In the coming months we will
be discussing this and/or other strawmen and will then decide.

> For now, it is too late to make a change that we
> do not all completely agree on.

We are not changing BLD.

> Other than this point on dialect identification, Michael, is BLD and FLD
> ready? If so let us know asap so we can freeze and review it.

The XML syntax is still in the works. As Harold said, should be ready by the
end of the week.


> -Chris
> Michael Kifer wrote:
> > 
> > 
> > On Sat, 05 Jul 2008 22:59:21 -0400 Sandro Hawke <sandro@w3.org> wrote:
> > 
> >> 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.
> > 
> > Agree completely. People designing private extensions are free to take whatever
> > they want and to discard anything that doesn't suit them. They can even come up
> > with a completely different interchange format. Nothing we can or should do
> > here.
> > 
> > The point of FLD is to provide a sufficiently attractive way for people to
> > easily design dialects without the need to go through the pain of a direct
> > definition (cf. the direct BLD specification vs. the derived spec).  But even
> > then they can decide to deviate quietly or convince us to change things. FLD
> > just says that for officially blessed dialects they should try the latter.
> > 
> > 
> > 	--michael  
> > 
> > 
Received on Monday, 7 July 2008 18:53:14 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:47:51 UTC