W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2003

SISR: More comments on April 2003 WD

From: Serge LE HUITOUZE <slehuitouze@telisma.com>
Date: Wed, 30 Jul 2003 16:28:20 +0200
Message-ID: <3AB3C7F30279254494C258DE38FE7CB969F50D@cedre>
To: <www-voice@w3.org>


Hello,

In addition to comments on last SISR Working Draft that I sent some time ago (10 June 2003), here are extra comments regarding what I think is a severe omission in the draft.

[As a side note, I mention that my earlier mail has not received any answer yet. I would appreciate having some information as to when it will be processed.]


In my previous mail, I noticed the lack of description of external rule reference processing.
More precisely, I noted the difficulty of making global tags work correctly when external rule references are present (one ends up with local "global tags").


I think there is another lack of description concerning external rule references.

As an example, consider the following grammar rule (cited at paragraph 6.1):
 $command = (set | turn)
            $object
            $state
            {$.o=$object;$.s=$state}
 ;

Now, suppose that the rule "$object" is defined in another module, giving a rule like:
 $command1 = (set | turn) 
             $<http://www.example.com/object>
             $state
             {$.o=$<http://www.example.com/object>;$.s=$state}
 ;

The problem with this variation using an external rule reference is that the variable name used in the right-hand side of the first expression in the tag is not syntactically correct.


The same problem arises with alternative notations for external reference rules (c.f. paragraph 2.2 of SRGS 1.0, 26 June 2002), e.g.:
 - "$<http://www.example.com/object>" (my example above),
 - "$<http://www.example.com/object.abnf>",
 - "$<http://www.example.com/foo#object>",
 - "$<http://www.example.com/foo.abnf#object>",
 - other variations using relative module names,
 - other variations using media-type extensions,
 - ...

I don't see any simple solution to solve this naming problem elegantly (inconsistency with ECMA syntax for variables).

The only proposition I can do is using "$$" to retrieve the semantic value of last expansion for future use. E.g., the example would become:
 $command2 = (set | turn) 
             $<http://www.example.com/object>
             {var obj = $$}
             $state
             {$.o=obj;$.s=$state}
 ;

This is more like a workaround, but that's the only practical "solution" that comes to my mind at the moment.

Anyway, whatever solution will be retained, this naming problem necessitates thorough documentation in the forthcoming SISR standard in order for grammar writers to be fully aware of this point.


Any comments?

--Serge Le Huitouze
Received on Wednesday, 30 July 2003 10:29:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:48:58 GMT