NL Semantics Markup Language for the Speech Interface Framework

Here are some comments on the following working draft:
Natural Language Semantics Markup Language for the Speech Interface
Framework NL semantics markup (20 November 2000):
<http://www.w3.org/TR/nl-spec/> http://www.w3.org/TR/nl-spec/ 
 
The specification mentioned above seems to be fairly broadly defined so that
it could be extended to accommodate the needs of various semantic
interpreters, as mentioned in the following section of the specification: 
"Extensibility: The specification should be extensible to accommodate
emerging and future capabilities of  automatic speech recognizers (ASR's),
natural language interpreters, and voice browsers. For example, it should be
compatible with statistical ASR's, mixed initiative dialogs and multi-modal
components."
 
There seems to be some issues in the choice of XForms (as defined in
<http://www.w3.org/TR/2000/WD-xforms-datamodel-20000815/>
http://www.w3.org/TR/2000/WD-xforms-datamodel-20000815/) as the data model
for the representation in the NL semantics markup language. A later version
of the specification should try to address questions 1. and 2. below (which
were raised by your comments in Section 7.6 included here for reference):
 
1.	How to add to the data model and have a DTD? How to combine multiple
data models so that developers do not have to duplicate redundant
information in all domains? 
 
"It would be highly desirable if components in the dialog system could
extend the data model so that grammars or reusable components could return
information that is additional to a base data model for, say, a time or date
component or grammar. With the current XForms specification it would be
necessary to provide a complete new data model in these cases. It is
possible that the Xforms working group may extend the Xforms specification
to include extensibility of the data model."
2.      How to account for semantic interpreters which make use of the
principle of compositionality?
"Similarly, the current XForms data model definition does not provide for
the re-use of complex type definitions, i.e. groups, in multiple locations.
Thus, to represent travel information consisting of both an outbound flight
and an inbound flight, it is not possible to define a single complex type
"flight_details" that is used for both outbound and inbound flight
information." 
Regards,
 
Evelyne Viegas
Microsoft Corp.
Natural Language Group