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

[Tanel Tammet]

Hi,

Thanks, Murray, for the most useful comments. I think
several things you point out should be put into the draft.

However, before submitting the third draft I'll wait for
more comments, and most importantly, real SCL abstract
syntax (and possibly, the human-readable syntax one as
well). SCL-in-XML has to follow what the SCL main draft
says, not vice versa.

Since you asked about some issues and I felt unsure
about some things you suggested, here come
comments to some of your questions/comments (and nothing more).


Murray Altheim wrote:

> Attached are my comments on the second draft. Primarily, I think
> before any reasonable discussion can approach these decisions
> on logic logically, there needs to be an agreed-upon set of
> application requirements upon which each decision can be judged.

Waiting for the SCL draft itself.

I tend to thing that we cannot realistically agree upon
a set of application reqirements. For example, when looking
at you large list of goals/requirements in your html version
of XCL, I thought about how abstract-and-generally-good
they are: that is, it is utterly nontrivial to agree
upon the priorities there and then put the priorities to
practice.

IMHO it is easier to work on the spec drafts and see if they
correspond to various ideas of people about what are the
crucial issues.

As for my own priorities (which surely not everybody agrees to
or understands in the same way), they'd be something like that,
in the rough order of importance:

- non-ambiguous and clear meanings
- ease of implementation (incl ease of understanding)
- easy extendability

It would be pointless to argue, say, about these three
"requirements": they are too vague, too intertwined, too
ambiguous. Requirements like these are IMHO understandable
privately, but very very hard for a group of people to tract
or to be used as metrics.


> But what about extensions? What if someone wants meet(i,j)? How
> will a processor know its correct arity?

In the tivial sense the arity of predicates and functions is arbitrary:
it is only important that the arity of "meet" is the same in
all its occurrences in the whole formula. This is easy to check
after or while parsing.

In the nontrivial sense Pat and other people argue strongly for
the SCL to incorporate non-fixed-arity constructions (translatable
to fixed arity). But this is another issue and I'd wait for
the SCL draft to see in which layer and how it is presented.

>>- Murray: shorten some, but no all, tag names, 
>>  for example <quant> instead of <quantifier>   
>>  
>>  Comment by Tanel: confusing to have some tag names as full
>>  names in English, some as shortened. Better to keep full
>>  names consistently. Since XML is very verbose anyway,
>>  micro-optimisations such as shortening the tag names are useless.
> 
> 
> Depends on the application. I've been hearing arguments from John
> and others about verbosity being an issue. Is it or isn't it? Saving
> half the number of characters used in element type names over a
> document of 300,000 elements is significant. The shortening leaves
> names that are still unambiguous. Are most CL documents expected
> to be large or small? 

What I claimed here is that micro-optimisations are pointless.
A few characters less here and there does not help. For the
compressed version of a file it anyway won't matter whether
an often-occurring tag name is a few characters shorter or longer.

>>- Murray: use XLINK namespace to refer to parts of other docs
>>
>>  Comment by Tanel: unclear why we need to to make other namespaces
>>  obligatory. Rather, let us introduce a parameter href (as
>>  xlink:href or just href in html) for referencing. This is subject
>>  to discussion.
> 
> 
> If you use the XML namespace you must declare it. You can't use xlink:href
> without declaring what "xlink" refers to. If you use "href" (or "foo",
> for that matter) application developers will have to write their own
> code for linking rather than using XLink libraries. The whole purpose
> of XLink wasn't simply to provide a linking syntax, it was to provide
> a whole methodology (and by extension, software libraries) for linking
> in XML. Using "href" will gain you none of that.

Why I am worried about other namespaces like XLINK. Suppose we say
that one should use the XLINK machinery for a highly important
purpose of including parts of other texts.

Then, in order to write inclusions in your SCL-in-XML (and also
in order to implement the software) you need to read through the
XLINK specs. I did that after you suggested XLINK. The spec is
big and nontrivial to understand: a bit intimidating if you simply
want to include text.

I'd say that for a person basically understanding FOL it
would be much easier to understand the SCL specs than
XLINK specs.

I am very worried about unnecessary complexities.

Writing a highly complex spec (or taking existing
complex specs quietly into your own as a requirement/assumption)
is a sure path to irrelevance.

Perhaps we could use parts of XLINK and put the relevant explanations 
from the XLINK specs into the SCL-in-XML specs directly, so that people 
would not have to read and understand all the XLINK specs?

To summarise: your arguments for XLINK are sound, but we should
definitely avoid the complexities they seem to introduce.
I do not know how to reconciliate these two opposing
viewpoints nicely.

>>  NB! Observe we could use XLINK namespace instead of putting these
>>  into SCL-in-XML namespace. In the current draft we DO NOT use XLINK
>>  namespace, just to simplify matters. This may be changed.
> 
> 
> Are you proposing that your "Simple CL" (what I've called XCL Level 1)
> incorporate linking features? Or is this left to a future version?

I do not know. Look at the argumentation above. More feedback
and materials necessary before we can make sensible decisions here.

I have put the linking machinery into draft version 2 to create
material for discussion and further thinking about this important
issue which has to be tackled sooner or later.

> I'm curious as to why you feel the need to namespace prefix SCL but
> not HTML. I'd do the opposite, since you can declare a default XML
> namespace (unprefixed) and have all non-SCL markup prefixed. I'd 
> have done the opposite. It saves space, is a lot easier to read,
> and the namespace prefixes are unnecessary. Your example didn't
> include the declaration for "scl:" so to compare fairly:
> 
>   <scl:quantifier xmlns:scl="http://scl_namespace_uri/"
>                   scl:name="forall" scl:variable="x"
>                   scl:id="foo">
>    <scl:predicate scl:name="r">              
>     <scl:term scl:name="x"/>
>     <scl:include scl:href="#bar">
>    <scl:term/>
>   <scl:quantifier/>
>   
> or
> 
>   <quantifier xmlns="http://scl_namespace_uri/"
>               name="forall" variable="x"
>               id="foo">
>    <predicate name="r">              
>     <term name="x"/>
>     <include href="#bar">
>    <term/>
>   <quantifier/>
> 
> They mean exactly the same thing to an XML processor.

Sure. I have avoided the default namespace usage in
the example (ie used namespace explicitly everywhere)
just to point out clearly that these and these
names are in the SCL-in-XML namespace.

A visual clue for reading the spec draft.

> You might want to mention the implications of IDs and the ID
> namespace, vs. values within the 'name' attribute.

I am not too fond of the attribute called "name"
I am using everywhere in the examples. It looks
a bit ambiguous for a human reader.

Would be nice if somebody comes up with a better
alternative name for this parameter than "name".


>>What is not prohibited
>>----------------------- 
>>
>>SCL does not prohibit using additional tags, parameters and parameter
>>values inside SCL text structures. 
> 
> 
> Why not?  Are you defining an interchange syntax or simply providing
> a playground for vendors and developers?

It is very very important that people can extend the core language.

Look at the actual, practical necessities in the TPTP library
of thousands of FOL problems. The TPTP author/maintainer Geoff
will tell you any day that it is absolutely necessary to add
various metainformation to formulas.

Now, these metainformation snippets should not be put into core
SCL. There is no way we can decide which should be in and which
should be out. People will build their language layers above
core SCL if SCL is to be used. If you cannot build your own
language layers, then you cannot realistically use SCL.

Language layers are OK if we keep the layer structure
modular.

>>In particular, users can invent their own parameters to 
>>mark formulas as belonging to different parts of the knowledge
>>base (for example: axioms for arihtmetic, theory of lists, 
>>knowledge of a particular person, a query, etc).
> 
> 
> Are there any rules for this, or do we expect to receive an SCL
> document and have to figure out what it means by hand? Will 
> non-standard SCL documents be labeled differently than ones that
> conform to the standard?

See above.

> The one thing I think necessary in order to determine the answers
> to design questions (and the first thing I did) is to define a
> set of requirements for SCL and have everyone agree to those 
> requirements. Then it's a matter of determining whether a specific
> option meets or fails the requirements. 

As I said in the early parts of this letter, this is IMHO
unobtainable in practice, if taken formally.

The people working on this do have informal requirements
in their heads, these change, and eventually some consensus
is reached, where the informal requirements are taken
into account.

> As it is now, you simply
> say you don't think a decision fits your understanding of the
> goals and toss it aside. Other people's requirements may be quite
> different than yours.

That is why the language we create is a collective creation,
not mine, yours, or anybody elses. We need discussions
like this one here.

Regards,
          Tanel