W3C home > Mailing lists > Public > public-rif-wg@w3.org > November 2007

Re: extensibility

From: Sandro Hawke <sandro@w3.org>
Date: Sun, 04 Nov 2007 07:31:00 -0500
To: kifer@cs.sunysb.edu (Michael Kifer)
Cc: Sandro Hawke <sandro@w3.org>, public-rif-wg@w3.org
Message-ID: <13452.1194179460@ubuhebe>

kifer@cs.sunysb.edu (Michael Kifer) writes:
> > I've fleshed out the Extensibility Design Choices page a lot more.
> > Feedback ASAP would be helpful.
> > 
> >     -- Sandro
> > 
> > [1] http://www.w3.org/2005/rules/wg/wiki/Arch/Extensibility_Design_Choices
> Related to extensibility (in fact, a big part of it) is what I was
> calling the "Framework for Logic Dialects" and was repeatedly 
> threatening to write down :-)
> (Well, we decided to split BLD into BLD proper and the framework. So, it is
> no longer a threat but my action item. The current BLD draft is too complex
> because the framework and the actual BLD are mixed in one document, so it
> was hard to see the forest for the trees.)
> Anyway, I started this document and wrote an overview of the framework in
> http://www.w3.org/2005/rules/wg/wiki/FLD/
> The rest of this document will be mostly cut and paste from the current BLD
> draft and the actual BLD will become a small part of the current draft.
> This overview should clarify the overall idea and will hopefully help the
> discussion of the extensibility issues.

Excellent, thank you.  As far as I can tell, what you're writing about
here is orthogonal to design questions I'm working on.  Do you see
places where they interact?  It seems like FLD languages will be a
family of RIF dialects where extensibility is much more constrained than
in RIF in general -- that seems good.

As a side note, I don't understand your definition of Data Types in this
document.  "... and no pair of distinct symbols in that symbol space can
be interpreted by the same string.  Symbol spaces which such special
semantics are call data types."  I'm not sure what "interpreted *by* the
same string" means, but it sounds like this idea would rule out xsd:int,
since 01^^xsd:int and 1^^xsd:int are the same thing, as I understand it.
Maybe you can clarify that text at some point....

      -- Sandro
Received on Sunday, 4 November 2007 12:31:10 UTC

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