[SCL] Re: Minor addendum

[Pat Hayes]

>I just wanted to add one point to accommodate
>Pat's concern about the W3C's preference for XML:

As I said, it has nothing to do with the W3C. The concern for XML is 
mine. From a recent email to Harry on this topic:

><Harry:> ....Since you have always been primarily motivated to 
>produce an XML-based standard...

That is not my primary motivation. However I do think that any 
proposed standard which claims to be intended for information 
exchange but does not come with a normative XML syntax is simply not 
going to be used by the vast majority of potential users, and will 
not be taken seriously by software engineers generally. I came to 
this conclusion reluctantly, kicking and screaming, but am quite 
convinced it is true, based on the discussions surrounding the RDF 
and OWL standardization process. I do however think that CL should 
offer a non-XML formal syntax which is sufficiently precise that it 
can be used by machines, as of course it currently does (the core 
dialect) and moreover that XCL should (as it does) offer users the 
option of including dialect text, including the core, without change 
as character data in an XCL document, so that one can produce legal 
XCL from any other dialect just by enclosing it in a suitable XML 
entity. This seems to me to provide the best of both worlds, though 
XML purists will complain that users can't check compliance of the 
PCdata with a DTD.

(Also, I have to say, having had now some experience of attempting to 
do software development in the post-XML world, that I can appreciate 
the reasons why this is the case. While by no means an XML groupie, I 
can see that one gains enormous practical advantages of ease of 
deployment from being in the XML world; and once in there, having to 
deal with even a slight part that is not in the XML world is like 
sand in a wheel bearing. So as standard writers it is simply perverse 
to require our users to not go into this territory, or not to be able 
to legally stay in it, if they are comfortable there.)

Let me give you an example. Since CL is so very general and 
expressive, its fairly easy to translate things like OWL into it. 
However, users want more than this: they want to be able to transmit 
some CL which is a translate of, say, OWL and also say that it is 
such a translation; that it is in the OWL-subclass of CL. Of course, 
a parser could find this out, but only at great expense. This kind of 
meta-information isn't traditionally part of any logic, and its not 
representable for example in the core dialect, and other CL dialects 
are not required to represent it in order to be compliant. It really 
has nothing to do with the logic as such; but is extremely useful 
when exchanging information: in fact, for some users, it is 
absolutely necessary, a first-base requirement; without this the 
entire standard will be useless. So what is the right thing to say 
about this kind of information, as part of a logic? You could say it 
was meta-information, but its a very limited and special kind of 
meta-information; and it applies to the text as a whole rather than 
to the individual expressions. The natural way to think about it is 
that it is markup, and the natural way to render it is by attaching 
extra properties to XML entities provided for just this purpose. This 
kind of (one might call it) textual meta-information is exactly what 
markup was designed for, and in that role it has been spectacularly 
successful, in a society-transforming kind of way. A normative XML 
syntax for CL can, and should, allow for this kind of markup. But it 
has no natural place in an abstract syntax, except in the rather 
bland form of being a kind of legal comment.
...

><Harry:>If one concrete syntax (e.g., XCL) is somehow special, then 
>I must have misunderstood.

...the XML syntax is special, yes, as it is the one intended and 
designed for information exchange on a network. Moreover, XCL has 
special provisions for encoding CL metadata, so it is more than 
simply a CL dialect in the usual sense. And it is particularly 
designed for CL itself. It is not a previously or independently 
designed logic notation such as KIF or CGIF. In fact there are no 
existing widely used XML notations for logic (which is one reason why 
its taken so long to write one; there are no precedents to follow.) 
So insofar as we are here proposing something, XCL is part of what we 
are proposing.

>JS> My feeling is that there will undoubtedly be
>>  two separate documents, but that the technical
>>  content of the two should be identical.
>
>I would just add that an XMLified notation is more
>important to W3C than it is to ISO.

I see absolutely no reason why this should be the case. The XML is 
important to software engineers who might be writing applications 
which refer to the standard. The identity of the standards body is 
completely irrelevant.

>  Therefore,
>the W3C version might also contain an XML expression
>of the semantics that is not contained in the ISO
>version.

Talking in this bland way about 'versions' seems to be predicated on 
a wholly imaginary continuity of effort. What group or body of people 
do you think are going to write these versions? (I have to say I feel 
slightly aggrieved here, as I seem to be the one who gets to write 
all the versions of everything. Speaking of which, weren't you going 
to write up a mapping from CGIF to CL? About a year ago? :-)

>Otherwise, I believe that the core syntax and
>semantics should be identical.

Please get this lined up with what Mike is saying. He doesn't want 
there to be a (concrete) syntax in the ISO document anywhere except 
in appendices.

Pat
-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayes at ihmc.us       http://www.ihmc.us/users/phayes
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://philebus.tamu.edu/pipermail/scl/attachments/20050302/fc2cc726/attachment.html