Re: First PS TF meeting

Hi Chris,

I'm currently in Poland and will be in a whole-day F2F meeting tomorrow. So, unfortunately I can not participate tomorrow.

I would like to point to the APS document which I have extracted some time ago from DTB, BLD and UCR:

http://www.w3.org/2005/rules/wiki/APS

-Adrian


From: Chris Welty <cawelty@gmail.com>
Date: Wed, 12 Nov 2008 10:49:18 -0500
Message-ID: <491AFAFE.7020008@gmail.com>
To: "Public-Rif-Wg (E-mail)" <public-rif-wg@w3.org>



Sorry for the continued delay getting this started - but let's go.  First 
presentation syntax task force meeting will be this Friday (Nov. 14) at 11AM EST 
(that's the usual RIF telecon time, but a different day).

Please let me know if you plan to attend so I can reserve enough zakim ports.

I'd like to start by reviewing Hassan's comments below.

-Chris



Hassan Ait-Kaci wrote:
 > Hello,
 >
 > This is an update on my on-going efforts to produce a working parser and
 > XML serializer for the BLD Presentation Syntax: Action 564, due on
 > October 31, 2008 (http://www.w3.org/2005/rules/wg/track/actions/564).
 >
 > I had already produced such a thing for the original specs - i.e., before
 > several changes were made that have had the effect of introducing several
 > rather nasty ambiguities and context sensitivity, both at the lexical and
 > syntactic levels - even just for the canonical PS (i.e., even w/o the DTB
 > shortcuts and Adrian's Abridged PS).
 >
 > I have been struggling trying to find workarounds to whatever snags have
 > popped up whenever I could figure any. However, there still remain some
 > tricky situations that require our attention (at least so that we produce
 > specs that are not so uselessly complicated to implement without ad hoc
 > hacks).
 >
 > It would be good that the PS Task Force convene sometime soon to discuss
 > these issues and how to resolve them.
 >
 > Here are some examples of what I have puzzled over (this is non exhaustive):
 >
 > 1) Tokenizing the argument of the Prefix and base directives is made
 >    uselessy complex by not enclosing the IRI in double quotes (viz., it
 >    forces a lexer to *parse* IRI's - as opposed to just read them off -
 >    for no purpose whatsoever, making the lexical nature of some characters
 >    context-sensitive (for example, ':' is used as a delimiter for CURIE's
 >    but not within IRI's; or, '#' is used as class membership, but not
 >    within IRI's; etc, ...).
 >
 >    A possible workaround is simply to double-quote them in the directives.
 >
 > 2) The minus sign ('-') now appears in some identifiers (e.g., ?diffdays =
 >    External(func:days-from-duration(?diffduration)). This would be no
 >    problem if we just considered '-' to be part of identifiers like '_',
 >    but it must also be seen as a literal character in order to recognize
 >    tokens such as "->" and ":-". While this is not a major hitch, it is
 >    unnecessary. (Not to mention the fact that '-' is the subtraction
 >    operator in the APS.)
 >
 >    A possible workaround is simply to disallow '-' in identifiers (say,
 >    using '_' instead) - as is the case in most programming languages.
 >
 > 3) The ANGLEBRACKIRI notation can be dealt with declaring '<' and '>' as
 >    quote chars, but this precludes them from being used as operators or
 >    punctuation.
 >
 > 4) UNITERM's are defined to be either positional or attributed, but not
 >    both:
 >
 >        UNITERM ::= Const '(' (TERM* | (Name '->' TERM)*) ')'
 >
 >    This creates an inherently unliftable reduce/reduce syntactic ambiguity:
 >
 >        =============================
 >        STATE NUMBER: 54
 >        =============================
 >        This state has conflicts:
 >
 >        Unresolved R/R conflict: choosing R82	over R84, 	on input 'IDENTIFIER'
 >        Unresolved R/R conflict: choosing R82	over R84, 	on input 'CLOSEPAR'
 >        -----------------------------
 >        [45] UniTerm --> Const 'OPENPAR' . UniTermBody 'CLOSEPAR'
 > 	       Preceding states: {22, 51, 95, 120, 127, 148}
 > 	       Follow set: {'CLOSEPAR'}
 >        [66] UniTermBody --> . Term_star
 > 	       Preceding states: {54}
 >        [67] UniTermBody --> . TermAttribute_star
 > 	       Preceding states: {54}
 >        [82] Term_star --> .
 > 	       Preceding states: {54}
 > 	       Lookahead set: {'EXTERNAL', 'NUMBER', 'LOCALNAME', 'VARIABLE', 
'STRING', 'IDENTIFIER', 'ANGLEBRACKIRI', 'CLOSEPAR', 'OPENMETA', 'COLON'}
 >        [83] Term_star --> . Term_star Term
 > 	       Preceding states: {54}
 >        [84] TermAttribute_star --> .
 > 	       Preceding states: {54}
 > 	       Lookahead set: {'IDENTIFIER', 'CLOSEPAR'}
 >        [85] TermAttribute_star --> . TermAttribute_star TermAttribute
 > 	       Preceding states: {54}
 >        -----------------------------
 >        With UniTermBody, go to state 55
 >        With Term_star, go to state 56
 >        With TermAttribute_star, go to state 57
 >
 >     A possible workaround is to use modify the rule to:
 >
 >        UNITERM ::= Const '(' (TERM | (Name '->' TERM))* ')'
 >
 >     (i.e., accepting mixed positional and attributed term bodies), and
 >     perform a check ex post facto.
 >
 > 5) According to http://www.w3.org/TR/rif-bld/#sec-ebnf-condition-language:
 >
 >       An IRICONST is the special case of a Const with the symbol
 >       space rif:iri, again permitting the shortcut forms defined in
 >       http://www.w3.org/TR/rif-bld/#ref-rif-dtb. One such specialization
 >       is '"' IRI '"^^' 'rif:iri' from the Const production, where IRI is a
 >       sequence of Unicode characters that forms an internationalized
 >       resource identifier as defined by 
http://www.w3.org/TR/rif-bld/#ref-rfc-3987.
 >
 >     However, this definition complicates tokenizing as it becomes
 >     impossible to distinguish the special case from the general one.
 >
 >     A possible workaround is to see an IRICONST as just a fully qualified
 >     constant; i.e., accepting even not "rif:iri" symbol spaces and
 >     performing the check ex post fact.
 >
 > Again, this is not an exhaustive list of issues. Be those as they may, I
 > will continue working on trying to produce a working [A]PS parser as my
 > time permits while on the road (I have been traveling and will be until
 > Nov. 11).
 >
 > It will be good that the PS Task Force discuss and find resolutions to all
 > such issues.
 >
 > Regards,
 >
 > -hak
 > --
 > Hassan Aït-Kaci  *  ILOG, Inc. - Product Division R&D
 > http://koala.ilog.fr/wiki/bin/view/Main/HassanAitKaci
 >
 >

-- 
Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
http://www.research.ibm.com/people/w/welty
-- 
Dr. Christopher A. Welty                    IBM Watson Research Center
+1.914.784.7055                             19 Skyline Dr.
cawelty@gmail.com                           Hawthorne, NY 10532
http://www.research.ibm.com/people/w/welty

-- 
Sensationsangebot nur bis 30.11: GMX FreeDSL - Telefonanschluss + DSL 
für nur 16,37 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Received on Thursday, 13 November 2008 21:17:49 UTC