RE: [BLD] PS specs amendments

Gary Hallmark wrote:

> you could have your lexer recognize Prefix(anyIdent  
> anything:except.a/right.paren) as a single token.

That is, *context-sensitive* tokenizing - talk about simple!
(And BLD PS ain't even a "real" language...) I thought that
the PS had no other purpose but to simplify the presentation
of examples. Apparently it must also please MK's taste.
His arguments (about equality, xsd:string - do not fly in
the least technically with me) and boil down his personal
sense of taste - which apparently this WG and most potential
implementers ought to share as a matter of principle.

Anyways, I am giving up arguing. I'll just put everything on
hold until MK convinces this WG that his sense of aesthetics
is both paramount *and* implementable. Which is fine with me,
because I do have other pressing things to see to.

TTFN,

-hak
--
Hassan Aït-Kaci  *  ILOG, Inc. - Product Division R&D
http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci



-----Original Message-----
From: Gary Hallmark [mailto:gary.hallmark@oracle.com]
Sent: Thu 9/25/2008 7:20 AM
To: Hassan Ait-Kaci
Cc: kifer@cs.sunysb.edu; public-rif-wg@w3.org
Subject: Re: [BLD] PS specs  amendments
 
you could have your lexer recognize Prefix(anyIdent  
anything:except.a/right.paren) as a single token.

Hassan Ait-Kaci wrote:
>
> Michael,
>
> Thank you for caring to explain. But we seem to be talking in
> circles. Let me make my position clear:
>
>    I don't care what the PS looks like - but I would expect it to be
>    parsable; at least if we wish for an implementation.
>   
> > Here we are arguing about the details, not substance. I just pointed
> > out that "..." don't look good here because "http:/bar.baz/fuz#" is
> > supposed to be an xsd:string according to the DTB syntax.
>
> Notwithstanding whether this "looks good" to you or not, I do not
> agree. We *are* arguing about substance when the issue is about how to
> actually parse your EBNF. As I pointed out repeatedly, the only place
> for these double-quoted occurrences are in the Base and Prefix
> *directives* not *grammar rules*. (See
> http://www.w3.org/2005/rules/wiki/BLD#Formulas, Item 7 of the
> definition of a Document formula.)  They define "shorcuts" precisely
> to allow CURIE notation to be used in the document following their
> occurrence. In other words, I do not agree that "...
> "http:/bar.baz/fuz#" is supposed to be an xsd:string ... ". The
> occurrence there one of a pragma - it is not part of the body of a
> document Uniterm or Frame. I do not see (nor agree) that it must be an
> xsd:string.
>
> > Right. What IRI is in Prefix and Base is up to us.
>
> Right. So, in what way is what I am suggesting contradicting this?
>
> > > So, unless I am missing something that you will explain to me, it is
> > > not that "#4 clash with the assumptions underlying PS&DTB" but rather
> > > that the assumptions underlying PS&DTB EBNF's are inconsistent!
> >
> > Nope. The example is simply wrong (the book(cpt:author->?Author
> > cpt:title->bks:LeRif) part).
>
> So what is the correct form? Is - or isn't - cpt:author allowed as the
> name of the argument to book? The current EBNF surely does not allow a
> CURIE there. So do you mean that *all* the named-argument Uniterm
> examples in the current specs are wrong? BTW, I do not understand why
> CURIE's should not be allowed as they are in the examples. All I am
> suggesting is that they be allowed as names as well (as the examples
> show).
>
> Regarding what I am proposing and what you are proposing, let me say
> the following: I feel pretty confident that I can provide an
> implementation with the simple amendments I suggested. If you have
> better, sexier, anythinger, ideas to make the PS *parsable* by non
> mind-reading voodoo priests, and can explain it to simple minds like
> me, then I am all for it... :-) Basically, the bottom line is:
> whatever suits your taste will be fine with me as long as it is simple
> to understand and *implement*.
>
> -hak
>
>
> -hak
> --
> Hassan Aït-Kaci  *  ILOG, Inc. - Product Division R&D
> http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci
>
>
>
> -----Original Message-----
> From: Michael Kifer [mailto:kifer@cs.sunysb.edu]
> Sent: Thu 9/25/2008 5:45 AM
> To: Hassan Ait-Kaci
> Cc: public-rif-wg@w3.org
> Subject: Re: [BLD] PS specs  amendments
>
>
>
> On Wed, 24 Sep 2008 17:44:43 -0700
> "Hassan Ait-Kaci" <hak@ilog.com> wrote:
>
> > Michael Kifer wrote:
> >
> > > On Wed, 24 Sep 2008 05:47:25 -0700
> > > "Hassan Ait-Kaci" <hak@ilog.com> wrote:
> > >
> > > > Hello,
> > > >
> > > > In the light of the recent discussions regarding parsing the
> > > > RIF BLD into RIF XML, I would like to submit the following
> > > > to this WG to decide.
> > > >
> > > > I propose to change the current RIF BLD EBNF to:
> > >
> > > Hassan,
> > >
> > > #1 and #4 clash with the assumptions underlying PS&DTB.
> >
> > Michael,
> >
> > In several mails preceding the one in which I listed these 4 points,
> > I pointed out in some details some of the problems caused by not having
> > them.
> >
> > Re: #1, allowing IRI's to appear unquoted (note that the <...>
> > notation poses no problem, while something it is something like:
> >
> >    Prefix ( foo http:/bar.baz/fuz# )
> >
> > does), for example, the ':' in the IRI is not the ':' of a CURIE. How
> > does a tokenizer know that ? All I am proposing is to change the
> > notation to:
> >
> >    Prefix ( foo "http:/bar.baz/fuz#" )
> >
> > so that the problem disappears.
>
> Here we are arguing about the details, not substance. I just pointed 
> out that
> "..." don't look good here because "http:/bar.baz/fuz#" is supposed to be
> an xsd:string according to the DTB syntax. This is why I mentioned <...>
> as a better alternative. (Also, see below before rushing to respond to 
> that
> one.)
>
> > Re: #4, in a recent email, I pointed out to Harold that the current
> > EBNF rules are inconsistent as they stand with his using CURIE's as
> > argument names (see
> > http://lists.w3.org/Archives/Public/public-rif-wg/2008Sep/0146.html).
> >
> > So, unless I am missing something that you will explain to me, it is
> > not that "#4 clash with the assumptions underlying PS&DTB" but rather
> > that the assumptions underlying PS&DTB EBNF's are inconsistent!
>
> Nope. The example is simply wrong (the book(cpt:author->?Author
> cpt:title->bks:LeRif) part).
>
> > > #3 is already in DTB, and I do not quite understand what you mean 
> by #2.
> >
> > #3 is indeed in the current spec, but not for named arguments Name's
> > that do not derive CURIE's although all the examples Harod uses employ
> > CURIE's for names of arguments.  Again, this is referring to recently
> > exchanged email on the RIF list (e.g.,
> > http://lists.w3.org/Archives/Public/public-rif-wg/2008Sep/0154.html).
>
> Yes, and this is a mistake. (See the end of the msg about the possible 
> ways
> out.)
>
> > Perhaps I have missed something that will explain to me.  Please go 
> ahead.
>
> as above.
>
> > > Re #1, double quotes are reserved for the abridged syntax for 
> strings in
> > > DTB. The abridged syntax for IRIs is <...>.
> >
> > Look at the examples. BTW, it is not true that "the abridged syntax
> > for IRIs is <...>." The notation <foo> stands for "foo"^^rif:iri.  The
> > use of IRI's in the EBNF is only limited to Prefix and Base grammar
> > productions. As they appear there in the PS, there is not quoting
> > and it is explained to "Recall that an IRI has the form of an
> > internationalized resource identifier as defined by [RFC-3987]."
>
> Right. What IRI is in Prefix and Base is up to us. We made it into a 
> sequence
> of unicode chars that form an IRI, but it could well be and IRICONST. 
> There are
> no objective criteria to decide, so we chose one of them (recall that 
> we were
> barred from making PS into a concrete language, and we were forced to
> include statements to that effect in various places).
>
> The problem is that "..." is a ^^xsd:string. So, if we want delimiters 
> then it
> should be something else. For example, '...'. Or we could make it into an
> IRICONST.
>
> > Again, what am I missing? Please explain.
> >
> > > I do not understand what you are trying to achieve with #4.
> >
> > What about: make the BLD examples consistent with the specs?
>
> As I said, the example was wrong.
>
> > > As far as I can see, it is not easy to reconcile this with PS, and 
> I do not
> > > understand why do you need this particular change.
> >
> > From what I can read and understand from the documents available today,
> > I beg to differ. But I concede that I may not have understsood 
> everything.
> > Again, whatever I am missing, I would be happy to understand.
>
> The EBNF is consistent with the normative English spec for PS.
> The examples have a problem. The easiest way out is to fix the examples.
> Alternatively, we could generalize the spec. But in that case the 
> solution is
> not what you have proposed but rather get rid of the simplifying 
> assumption
> that the argument names come from a separate set ArgNames and instead use
> arbitrary constants there.
>
> I don't know whether it is ok to do such a generalization after the 
> last call,
> and I am not sure that this generalization is a good one either.
>
> > Thanks for explaining.
>
> Thanks for spotting the mistakes in the examples :-)
>
> michael
>
>
> > >         --michael
> >
> > -hak
> >
> > >
> > > > 1. allow IRI's only within double quotes;
> > > >
> > > > 2. do not perform expansion of relative IRI's;
> > > >
> > > > 3. allow CURIE's everywhere as specified in the EBNF today
> > > >    as CONSTSHORT's;
> > > >
> > > > 4. allow Name's to derive CURIE's.
> > > >
> > > > With the above simple amendments, I am confident that I can
> > > > specify a workable tokenizer and Jacc grammar for a new
> > > > version of my BLD->XML tool.
> > > >
> > > > In order to speed things up a bit, it would be nice if the
> > > > above issues could be settled soon, so that I can proceed
> > > > with the new release.  I will be travelling starting
> > > > tomorrow and will spend the whole month of October working
> > > > in ILOG France.  I will not attend this F2F in NYC - not
> > > > even remotely (in fact I will be in planes most of its
> > > > duration). I will attend the F2F debrief planned for next
> > > > Tuesday's telecon.  Only after then will I have time to
> > > > start implementing the above amendments.
> > > >
> > > > Have a fun F2F in NY, NY (my kinda town!)...
> > > >
> > > > Cheers,
> > > >
> > > > -hak
> > > > --
> > > > Hassan Aït-Kaci  *  ILOG, Inc. - Product Division R&D
> > > > http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci
> >
> >
> > -hak
> > --
> > Hassan Aït-Kaci  *  ILOG, Inc. - Product Division R&D
> > http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci
> >
>