[Admin PS] Agenda for Presentation Task Force telecon Nov. 14

AGENDA Teleconference
W3C Rules Interchange Format (RIF) Working Group
Presentation Syntax (PS) Task Force
14 November 2008
Time:
1600 UTC, 0800 (West US) 1100 (East US) 1600 (London) 1700 (Paris)

Duration: *60 min*

Bridges: +1.617.761.6200 (US), +33 4 89 06 34 99 (F) or +44.117.370.6152
(GB)
Conference code: 74394# ('RIFWG')
IRC Chat: irc:irc.w3.org (port 6665), #rif
Web-based IRC (member-only): [http://www.w3.org/2001/01/cgi-irc]

Chair: Chris Welty
Scribe: TBD

Please note that RIF WG telecons are for attendance only by Working
Group Participants and guests invited by the chairs.

Agenda:

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

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