[SCL] new draft

[pat hayes]

>At 10:34 2003-12-31 -0800, pat hayes wrote:
>>  >SCL people-
>>  >
>>  >I'm new to this list.  I thought I was subscribed to the KIF list
>>  >and I found out last week at the INCITS/L8 meeting that the list had
>>  >(again) changed and I was no longer part of the discussion of the CL
>>  >activities.
>>
>>  The SCL list is open to anyone, but please be clear that its purpose
>>  is limited, with a sharper focus than the CL effort, and that this
>>  list is intended for technical discussions which are now reaching a
>>  fairly late stage. You can see the origins of SCL in the early part
>>  of the SCL email archives. Issues of ISO compliance in particular are
>>  not appropriate for this forum.
>
>Harry and Mike G. told us that the discussion of CL had moved to the SCL list.

I wish they had not done that. I formed the SCL group with the 
express intention of getting the technical work done without being 
bothered by the requirements of operating within a bureaucratic 
framework of any kind.  Once this is done, the SCL work is finished. 
I had hoped to be able to say it would be done by the end of 
December, but we are close to the end now.  Once this is done, the 
results will be made freely available to any organization which might 
wish to make use of it, including ISO and the W3C. However, the 
actual business of maneuvering this through the ISO process is not 
one that I personally wish to be responsible for, and Harry has 
volunteered to do that.

>  I was part of the CL list, but I wasn't aware that the discussion had moved.

In my view, it did not. I have never been responsible for the CL 
effort and in my view the CL effort is still run by Mike G, and now I 
guess Harry.  I believe it is on hold, waiting for SCL to be finished.

>Since the purpose of the discussion, as described by Harry and 
>others, is to develop a "CL specification" that is intended for 
>submission to INCITS/L8

That is most definitely not the purpose of the SCL effort. I have had 
no dealings with ISO and am not likely to have any in the future. 
The single ISO meeting I ever attended left me with a strongly 
reinforced sense that ISO was not an organization I ever wish to 
become involved with.  My primary target is the W3C, but others in 
the SCL group have other ambitions.

>stand the nature of this specification before it hits INCITS/L8.  Of 
>course, it is always possible that we (L8 and SCL) don't have any 
>communication at all, but then it doesn't facilitate the 
>harmonization of stakeholders' needs, such as those of L8 and this 
>particular group of people (SCL).
>
>If this work is to become an ISO/IEC standard, then there is much 
>preparation to be done -- which means a fair amount of explanation 
>and rationale so that the US members (and later on, other National 
>Bodies - NBs) can make an informed decision about the document.

Right. I am not prepared to accept the burden of trying to educate an 
ISO committee about logic to the point where it can make an informed 
decision.

>  If they don't understand the document, they won't approve it.

If they do not understand what is going on, then it is probably for 
the best that they do nothing,. A badly written, uninformed standard 
is likely to be actively harmful, and worse than no standard at all.

>And the document is likely to have some changes as it makes progress 
>from "consensus among a small group of people" (SCL) to "consensus 
>among ~20 nations" (JTC1/SC32/WG2, JTC1/SC32, and JTC1).  In 
>addition to NBs, there are other organizations that will have input 
>on this, such as JTC1/SC22 (Z was developed in SC22/WG19).

Like I said, take this up with Harry. Harry is your man for dealing 
with the organizations.

>
>>  >One point I hope that SCL people can address is: how does this SCL
>>  >(or CL?) differ from Z?
>>
>>  Please raise this issue on the CL list, not the SCL list.
>
>OK, I'll ask the queston there.
>
>>  >Isn't SCL just a subset/profile of Z?
>>
>>  No.
>>
>>  >   Based on the draft document, it appears to me that SCL can be
>  > >specified by pointing to a portion of the Z standard and adding a
>>  >few "customizations".  Perhaps I'm wrong, so could someone explain
>>  >the relationship?  Maybe there is a prior E-mail where this has
>>  >already been discussed, so could someone point me to that E-mail
>>  >discussion?
>>  >
>>  >Regarding the new draft, I'm having problems with the form of the
>>  >specification of SCL.  For the formal specification of standards for
>>  >languages like SCL, the specification should
>>
>>   From where comes this criterion for what a specification 'should' do?
>>  Absent any documentary guidance from a higher authority, it seems to
>>  me that the specification should be written by the people writing it.
>
>The "should" comes from experience in what will get approved in 
>standards.  So there isn't a "higher authority" making this 
>requirement via a document, per se, but the authorities that approve 
>this (INCITS/L8, INCITS/EB, ISO/IEC JTC1 SC32 WG2, ISO/IEC JTC1 
>SC32, ISO/IEC JTC1) have a strong desire for harmonization, 
>non-duplication of efforts, and the use of common formal descriptive 
>techniques.  So if you want to have your document progressed to 
>higher levels, you need to know what some of their concerns are.
>
>Having 20+ years experience in ICT standards, I'm sharing my 
>personal opinions on what works and what doesn.  I have a pretty 
>good track record on anticipating issues that impede 
>consensus-building.
>
>>  >  detail the syntax of the language (the draft claims the metasyntax
>>  >is EBNF, but it is not
>>
>>  It is now.
>
>I'm looking at the draft:
>
>http://www.ihmc.us/users/phayes/SCL_december_2.HTML

Look instead at

http://www.ihmc.us/users/phayes/SCL_december_3.HTML

<snip>
>
>         iso ebnf 14977
>
>You'll find a bunch of references.  FYI, in addition to Z, in my 
>involvement in SC22 and SC32, I have also made a formal request for 
>ISO/IEC to make this standard free-of-charge and publicly available. 
>JTC1 has approved the request about a month ago in Singapore and it 
>is now awaiting approval at the top levels of ISO and IEC.

Well done!!  As you would guess, I thoroughly approve of this.

>
>I didn't convert all of the grammar to ENBF yet.  I did notice some 
>potential bugs and some areas for improvement.  Regarding potential 
>bugs, I notice:
>
>         - There are several ambiguous parses.

I think you will find that the current version is unambiguous.

>For example, if S1 and S2 are sentences, then the sequence "not S1 
>implies S2" produces an ambigous parse: is it "(not S1) implies S2" 
>or "not (S1 implies S2)".  This is not only ambiguity -- there are 
>several others.
>
>         - There are several duplicate syntax fragments that could be 
>reduced -- this would simplify the normative wording that would need 
>to be written to support the syntax rules.

Some of the syntax is apparently 'redundant', and are so for strict 
parsing purposes, but the extra categories are used in the semantics. 
I agree however that this is a ticklish point and maybe we will 
simplify the syntax later.

>
>         - The non-terminals "name" and "specialname" are not defined 
>in the syntax.

As of now, specialnames are simply a subset of names which play a 
special role in the semantics.

>
>         - There is no discussion of whitespace or the practicalities 
>of character processing.  For example, while the conceptual model of 
>processing charcters might be ISO/IEC 10646 (not Unicode), there are 
>the practical issues of: (1) proper inclusion, exclusion, and 
>preservation whitespace, (2) the relationship of whitespace to the 
>syntax, (3) the need to "escape" characters that have lexical or 
>syntactic significance, (4) the handling of newline characters.  For 
>typical programming language standards, these are *specified* (but 
>not necessarily implemented) in two or more passes of translation: 
>one pass on lexical analysis (e.g., getting the whitespace, 
>newlines, and escaped characters fixed up right) and one pass on 
>syntactic analysis -- there may be other passes (more on this in a 
>separate E-mail regarding the interpretaton of headers).

Right, I am aware of this stuff but did not want to spend too much 
time on syntactic details at this stage, since the quibbles of 
surface syntax are REALLY not important for SCL. However, I bow to 
the inevitable, and had already developed a syntax for KIF which is 
based on a left-to-right lexical tokenizer algorithm which only 
requires a 2-character lookahead at worst, and have now adapted that 
for SCL.  I am also working with some folk here who are building an 
ODM model of the SCL abstract syntax, based on the core syntax in the 
above-cited document.  This should be done and will be freely 
available in about a week or so from now: I will announce it to the 
list when it is ready.

>
>Speaking of programming languages and their standards, I don't 
>understand why you are resistant to taking some of the tips and 
>reusing them?  I understand that you have a concern about the 
>execution vs. declarative aspects of the statements -- OK, a 
>reasonable discussion to have.  However, it appears to me that you 
>are dismissive of all of the work in programming language standards

Sorry if I sounded snappish, Im feeling rushed. I am not dismissive 
of all this work, and will use it wherever I can.  But I do rather 
resist taking it for granted that what we are doing MUST be modelled 
exactly on that other work.

>  -- stuff that can really save us time.  For example, programming 
>language standards take a different approach towards developing the 
>the EBNF for their grammar: the result is fewer ambiguities and more 
>consistent machine parsing of the "language".

Yes, but again, the requirements of parsing a programming language 
are different. In the case of a logic, it is not even obvious that 
lack of ambiguity is always desireable (though to be sure, that would 
be a natural first assumption). For example, it may well be the case 
that by adding new logic text to a corpus, the parsing of other texts 
may be revised.

>Also, programming language standards have much experience in 
>approaching these kind of specification problems, such as certain 
>problem-solving technique that greatly simplify the understanding 
>and improve the consistency of interpretation (e.g., approaching 
>language specification via a series of translation phases).

The new syntax is deliberately based on such an approach, assuming a 
left-to-right lexical-tokenizing phase.

There are all kinds of other issues, however. For example, the 
internationalization subcommittee of W3C frowns on any lexical 
conventions which depend on an assumed left-to-right character string 
organization, since Unicode string comparison in non-European 
languages often treats character code strings differently during text 
normalization. The ability to be included in text markup without 
causing damage to the surrounding text-processing conventions is 
likely to be important to future applications of SCL.

>
>Lots of the stuff applies, even if you aren't generating executable 
>code.  Hopefully, you may gain further appreciation of much of the 
>serious work that has been done in this area in the past 2-3 decades.
>
>If you would like me to spend time improving the grammar and 
>preparing a strawman for the lexical analysis, I will.

Many thanks. It might be good to wait for the ODM model to be 
finished, to avoid duplication; but certainly, any input you can give 
would be greatly appreciated. Particularly as I have to confess that 
syntactic details are not the topic that makes my heart beat faster.

>
>>  >) and each of the "productions" would have a semantic description,
>>  >i.e., the meaning of instances of the production (combined: syntax
>>  >and semantics).
>>
>>  The semantic is gathered into one table, which is the preferred way
>>  to described a model theory. It is particularly important in this
>>  case since the syntax does not suffice in isolation to provide the
>>  semantics precisely.
>>
>>  >I don't see a one-to-one mapping of "productions" to semantic
>>  >descriptions, so my sense is that the semantic description is
>>  >incomplete in the current draft.  I'm sure that a precise
>>  >description is intended, but I am not seeing it within the current
>>  >draft.
>>
>>  The SCL document is not a draft ISO standard document. But I welcome
>>  suggestions for better presentation.
>
>See my suggestions above.

Yes, noted, thanks. John Sowa agrees with you, BTW.

>
>>  >Also, could the terms be defined in the standard?  There are a good
>>  >number of terms that appear to have a specific meaning (e.g.,
>>  >vocabulary, extension, etc.), but they don't mean what they say in
>>  >the OED (the OED's definitions are not precise enough for this
>>  >subject area) and the technical meanings can easily be misunderstood.
>>
>>  We plan to write and include a glossary but will leave that until the
>>  document is more complete and more stable.
>>
>>  Pat
>
>I read in one of your other E-mails today:
>
>         ... The only issue is how to define the scope of a name when 
>naming a...er...thingie, for subsequent importing. So I suggest we 
>adopt 'text' for a sequence or set of sentences, and 'module' for a 
>piece of text with a name and (optionally) a header, and I will 
>learn to avoid saying 'ontology' in an SCL context.
>
>Your statement above seems reasonable.  So why not add the definitions:
>
>         text: sequence or set of sentences
>
>         module: text associated with a name and, optionally, a header

Yes, I thought those definitions were present, but I see they got 
lost in an edit. I will put them back in.

As I said, we will build a glossary when the text is actually 
written.  In fact, I plan to insert formal definitions of all terms 
of art, with a glossary of the 'normal' terms and all occurrences of 
a technical word hyperlinked to their definitions, in the style used 
in

http://www.w3.org/2001/sw/RDFCore/TR/WD-rdf-mt-20030117/

but my experience has been that to attempt to do this other than 
fairly late in the writing process is a serious mistake, producing an 
editing nightmare when changes are made to the text.

>
>While these definitions might be refined over time, it is extremely 
>helpful to have key terms defined *now* -- it helps avoid our 
>tendancy to see terms and read our own interpretations, which might 
>be imprecise, incorrect, or inconsistent.  A good one-liner 
>definition goes a long way. :-)
>
>Happy New Year

And to you and yours

>-FF
>
>______________________________________________________________________
>Frank Farance, Farance Inc.    T: +1 212 486 4700   F: +1 212 759 1605
>mailto:frank at farance.com       http://farance.com
>Standards/Products/Services for Information/Communication Technologies
>
>_______________________________________________
>SCL mailing list
>SCL at philebus.tamu.edu
>http://philebus.tamu.edu/mailman/listinfo/scl


-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(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/20040101/5ca748ae/attachment-0001.htm