[SCL] Re: The second draft for XML syntax for CL

[Murray Altheim]

[Since you seem to be replying mostly to my comments, I'll reply.]

geoff at cs.miami.edu wrote:
> Hi Tanel,
> 
> Sorry I've been so long getting to this ... I have only a few comments
> to this and the next email. My depth of understanding of XML and associated
> issues limits my useful ness in the technicalities. But on the side of
> a useful syntax for logic problems ...
>
>>>- Pat: XML is ugly, verbose, unreadable, hardly useful.
>>
>>Having an XML notation for CL will provide a means of incorporating 
>>it with a huge amount of existing software and documents. XML is the 
>>de facto standard for interchanging data nowadays on the Internet. 
>>
>>Whether it's ugly, verbose, unreadable, etc. is a matter of opinion
>>and irrelevant.
> 
> It's not black and white. The more verbose your syntax gets, the more
> people who may be alienated. So it's not just "use XML or don't", it
> can affect decisions in designing the XML syntax (i.e., avoid verbose
> XML).

First, we were discussing XML in general as a verbose notation, not
specifically the design of a specific syntax. But as regards markup
design, I'm not sure on what your opinion is based. There are a great
number of factors involved in designing a suitable syntax, and these
must be taken into account more than any measure of verbosity, which
is really irrelevant after the other, more important, factors are
taken into account.

For example, it seems "simple" to put content in attribute values.
Well, if one wants to add attributes to that content, it's apparent
that the content should be element content. This is a recursive
issue. Also, there are matters of simplicity that are in direct
conflict with verbosity -- sometimes a more verbose syntax is in
actuality a lot simpler, such as having one element that is typed
by another rather than a myriad of "simple" elements, if you need
extensible typing.

Put it this way: XML was designed by some of the industry's experts,
people with decades of experience in SGML. What does one of the
requirements on XML say? "Terseness in XML markup is of minimal
importance." I've now been doing markup work for over a decade,
and honestly, the last thing to consider is verbosity. If people believe
an XML concrete syntax for SCL is going to be commonly hand-authored
rather than the product of a transformation, I think they need to
have their heads examined. HTML is one thing, but logic? Think of
the potential for syntax or human interpretation errors. ugh.

It's best to avoid the cliche'd rules about markup design and look
at a distinct set of requirements. That's why my XCL design [XCL] had
its requirements up front. We can then debate the requirements rather
than the specific syntax, and following agreement on the requirements
a design is much more straightforward, and also one can then determine
whether the design meets the requirements rather than it all being
about aesthetics and taste, which is kinda pointless.

[...]
>>>- Geoff:  unique existence is something useful, the generalized form which the
>>>   TPTP will support is 
>>>         ? [1:X,2:Y] : p(X,Y)
>>>   meaning there are exactly one X and two Ys such that p(X,Y).
>>>   
>>>   Comment by Tanel: no clear need to introduce this into minimal core
>>>   (we want to keep the core minimal!). Could be introduced in extensions.
>>>   Easy to give an extra parameter to quantifier tag, like this:
>>>   <quantifier name="exists" variable="x" count="2">
>>>   indicating that we say that there are exactly TWO instances.
>>>   However, bringing this into core creates unnecessary complications.
>>>   Let us see whether it will be in the SCL core - if yes, we can put
>>>   it into the XML concrete syntax.
>>
>>This could be introduced as a PSI rather than as new syntax. As in my
>>last comment.
> 
> Help, what's PSI? Anyway, I support Tanel with a minimalist approach in
> the core. So, as I suggested in my response to the first draft, I would
> say the typing is not core - you open any text on mathematical logic and
> read the definition of FOL ... not a word about types. I suggest you can
> take types out of the core.

What I'm referring to as "types" are inherently in the core, just a
very specific set, essentially anything that can be typed. If you
look at the current SCL draft, in the content of <formula> you see
types. There are two quantifier types, <forall> and <exists>; there
are five connective types, <and>, <or>, <implies>, <iff>, and <not>.
In this suggested syntax, these are literally called "element types"
(not "tags"), but they don't have to be expressed necessarily as
element types. XML doesn't require that.

So what I did in XCL was simply make all of this explicit and
extendable. It's a very straightforward process to discern if a
specific XCL document conforms to the core or not, as a matter
of XML or application-level validation. A conformant XCL document
is one that uses only the agreed-upon set of types described in
SCL. (I'm deliberately using the word 'types' loosely to suggest
that we have a great deal of freedom in the XML design.)

These five examples are semantically identical, from the perspective
of representing a generic SCL quantifier "forall":

   1.   <forall/>

   2.   <quantifier type="forall"/>

   3.   <quantifier>
          <type>forall</type>
        </quantifier>

   4.   <quantifier>
          <type name="forall"/>
        </quantifier>

   5.   <quantifier>
          <typeRef xlink:href="http://purl.org/xcl/1.0/#forall"/>
        </quantifier>

So while the first is very simple, it's impossible to extend the
XCL syntax without introducing new elements. The second and fourth
have the advantage of being validate-able using a DTD (using
enumerated attribute values), the third and fifth could be
validated using RELAXNG or XML Schema. The second and fourth are
my choices for what I've called XCL Level 1 and 2.
Basically, in XCL Level 1 we allow only the <type> element (#3),
and in XCL Level 2 we allow either a <type> or a <typeRef> (#5).

Again, remember that from an XML perspective, all five are
semantically identical -- any perceived differences are people's
aethetic opinions alone. It's not there in the XML.

###  PSIs.

A PSI is a Published Subject Indicator, a URI published as an
identifier under a specific set of guidelines designed to improve
longevity, provide revision and authoring metadata, and definitions
of meaning. In the example above, the purl.org URL would be
published as a PSI, such that resolving it would point to a web
page that described what it meant, i.e., pointing at the SCL
specification's section for "forall".

>>>- Murray: introduce <doc> tag for arbitrary doc strings
>>>
>>>  Comment by Tanel: unnecessary, since we have a "comment" parameter
>>>  for free-form documentation strings. As said before, we do not
>>>  want to complicate the term structure by additional tags not
>>>  correspoding to SCL abstract syntax term elements. This
>>>  might change in case SCL abstract appears and demonstrates
>>>  that the mapping to XML term-as-tag would be useful.
>>
>>If you use an attribute (it's in XML an attribute rather than a parameter)
>>you can only use ASCII data, unless you want to force your users to write
>>strings that use stuff like &#8704;x:&#8895;, etc. for documentation. And
>>stuffing long strings in attribute values is prone to errors, such as 
>>when people accidentally have a quote markup within their documentation.
>>And you won't be able to extend documentation features by adding their
>>own markup, use XHTML, use links, etc. There's no reason to use attributes
>>over elements from markup standpoint. If people are expected to be typing
>>SCL it might be an issue, but if your requirements expect the predominant
>>use to be hand-typed SCL, we're working on different projects. 
>
> Oooh, yes, Murray is right. The addition of the <formula> was a step in
> that direction, but I see that a place for arbitary documentation would
> be useful in practice.

Yes, this is my point about verbosity in a nutshell.  Using the
modular XHTML DTDs, I could fairly easily add a subset of XHTML
markup (say, a restricted set of what could appear within <p>) to
the XCL <doc> element, so users could have access to rich markup
(including links) in their XCL documentation. (This would be in
some extented version of the language, not the core).

>>>- Murray: inroduce <type> tag to indicate the type of a variable
>>>
>>>  Comment by Tanel: this would open up a possibility to give
>>>  complex types attached to variables. The current proposal
>>>  of using "type" parameter only allows predicate names to
>>>  be used as types, simplifying the type usage. As said before,
>>>  we want to avoid new tags and complexities in structure.
>>
>>Currently, it does not open up any such possibility, as in XCL Level 1
>>the content is declared as PCDATA (character data). In Level 2 the 
>>ability to add a link here is important in that it will allow XCL 
>>documents to reference existing ontologies and their types. Use of 
>>an attribute value here has the same problems as in my last comment.
>>You won't be able to open this up later (unless you are willing to
>>have a redundant 'type' attribute and a <type> element.
> 
> See, I solved it ... just take types out of the core.

Well, as I've said, what I've been calling types are already in SCL,
so it's better to be able to refer to them via URL/PSI. IOW, if you've
got a list of quantifiers, connectives and predicates, make up a URL
for each of them and publish the list along with the SCL specification.
It does no harm, and allows people creating concrete implementations
to point at them as subject identifiers. If that's too much trouble,
make sure the sections in the HTML document have link targets, and
just use those as the PSIs.

And while I always hear hackles raising when I discuss this, I will
again point out that none of what I've proposed alters the *semantics*
of SCL. All of the issues in this message are involved with the
concrete syntax, i.e., alternative ways of saying the same thing in
XML.

Murray

[XCL] http://purl.org/xcl/1.0/
...........................................................................
Murray Altheim                         http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK                    .

   "We can now hypothesise with some confidence that those apparently
    happy, calm Buddhist souls one regularly comes across in places
    such as Dharamsala, India, really are happy," said Professor Owen
    Flanagan, of Duke University in North Carolina. -- BBC News
    http://news.bbc.co.uk/1/hi/health/3047291.stm