[SCL] Re: Report on Common Logic

Mon Nov 3 10:45:10 CST 2003

pat hayes wrote:
> John Sowa wrote:
>> Murray Altheim wrote:
>
>>> After that's done, an XML syntax still isn't completely
>>> straightforward. Like any language, you need to decide exactly
>>> what you're trying to do with it. Just *one* of the questions
>>> I brought up early on was "web-enabled" or not? Use of URIs or
>>> not? Any extensibility, so it can be the basis of other languages?
>>
>> Those answers were decided long ago:  web enabled, yes;
>> URLs, yes; extensibility, yes; and basis for most common
>> declarative languages, yes.
> 
> Wait: when was that decided? To create a web-enabled syntax is indeed 
> one goal, but not the immediate one (ie aiming at Dec 17); the aim there 
> should be a basic SCL-XML exporting syntax allowing SCL to be ported 
> through an XML pipe, with the minimum of bells and whistles. URLs are 
> permitted but not obligatory (as in SCL generally) and I do not feel 
> that the XML syntax should be particularly extendable or web-enabled 
> (whatever that means, it requires a lot more discussion): SCL is itself 
> extendable, but there is no need to provide for extensions in (this) XML 
> syntax: any extensions would be changes to the syntax and hence to the 
> XML. So my answers (in the short term) would be:
> web enabled, no; URLs are used but not mandatory; extensibility, no. I 
> realize this makes it into a very boring exercise for an XML/web expert, 
> but that is what we need done by the 17th (actually by about the 12th).

I'm not concerned any more than you with this being "boring". I am
concerned with its usability and whether or not it meets a set of
requirements. Those two things are of course inextricably tied. I
would still prefer a set of specific requirements for this work; I'm
guessing this isn't going to happen, so perhaps I can just field
questions and see if nobody screams when I answer them as best I can
based on what I see on the list, rather than in a requirements document.

   Web Enabled:
      1. Do we want XCL documents to be able to refer to other XCL
         documents over the web? This would be how modules could be used
         to construct larger statements/formulae/ontologies/etc.
      2. are XCL documents meant to be exchanged over the Web?
      3. are there meant to be internal link targets within an XCL document?
      4. compatible with XLink or use its own linking structure?

   URIs or not:
      1. If URIs are permitted in SCL, do they actually *mean* URIs, or
         are they just string identifiers? Is there any sense of them
         being dereferenced? Is there any requirement as to what is at
         the other end of the reference?
      1. are URIs in XCL merely meant to be contained as strings, or
         actually treated (in syntax) as URIs? Is there to be any
         differentiation between their various uses (as strings or as
         links)? In the case of links, do you want a mechanism to include
         link semantics (e.g., role attributes), so that one *kind* of link
         is differentiated from another? Is this list of link semantics
         fixed or extensible? E.g., In HTML, there are many dozens of kinds
         of links and link semantics, some fixed, some stated by the user.
      2. Are there any restrictions on the use of URIs within XCL? A query
         language beyond fragment IDs ("#foo")? Use of XPath suggested or
         permitted? If only intra-document links are used, do you want to
         use XML IDs (which are guaranteed unique), but have naming
         constraints (XML Names only, no weird characters or spaces)? If
         not, how do you want to design the link structure? (There are a
         *lot* more questions then.)
      3. If URIs are not used, how are references made between various
         parts of the grammar? Are there one or two different mechanisms?
         If two, how do they interact? (I'd recommend one: use URIs, but
         if you don't want external linking to other documents, simply
         prohibit it, either in the spec prose or in the DTD/schema, and
         use the XML IDs.)

   Extensible:
      1. Are documents conforming to the XCL spec required to include
         only XCL content, or can it be mixed with other markup? I.e.,
         the XML Topic Maps spec forbids any mixing within an XTM document.
      2. Do we want the element and attribute names to be fixed? A reason
         why we might is that XCL may be used for different purposes. For
         authoring and reading the markup (which will often or even
         usually be done by humans, sad to say), we'll want the element names
         to be human-readable (e.g., "<formula>", "equiv"), whereas for
         really large documents, people may want "<fm>" "eq", etc. to save
         space. This kind of thing reduces interoperability, but XSLT can
         easily be used for transforms. It'll also depend on the markup-
         to-content ratio.
      3. Is there one XML Namespace prefix permitted, or anything goes?
         I.e., is the default (either "" or "xcl:") fixed?
      4. Are there any DTD- or schema-based mechanisms provided for
         extending XCL, or is this left to others? (If not, the ways that
         people might alter the DTD may create incompatibilities, whereas
         if everyone uses a provided mechanism, this will make DTDs/schemas
         interoperable and easier to use).
      5. If it's know that XCL will be extended beforehand, do we want to
         provide the hooks so that those DTDs/schemas can be built upon
         the core XCL DTD/schema, or would those projects have to start
         from scratch?

Some of these things are implemented in the DTD/schema, others are
constrained in the prose of the spec.

There are perhaps other issues, I'm just pointing out that this is not
straightforward.

Murray

......................................................................
Murray Altheim                    http://kmi.open.ac.uk/people/murray/
Knowledge Media Institute
The Open University, Milton Keynes, Bucks, MK7 6AA, UK               .

  White House defiant despite deadliest strike on forces since end of war
    http://www.guardian.co.uk/Iraq/Story/0,2763,1076578,00.html
  US defiant after Baghdad attack
    http://news.bbc.co.uk/1/hi/world/middle_east/3186074.stm
  US defiant on X-Ray prisoners
    http://old.smh.com.au/news/0202/10/world/world7.html
  US defiant on war crimes court
    http://www.cnn.com/2002/WORLD/europe/07/01/bosnia.peacekeeping/?related
  US stands defiant despite isolation in climate debate
    http://www.guardian.co.uk/bush/story/0,7369,526607,00.html
  US defiant and unrepentant over largest chemical warfare campaign in history
    http://www.guardian.co.uk/weekend/story/0,3605,923715,00.html
  Americans defiant over growing divisions with Europe
    http://www.telegraph.co.uk/news/main.jhtml?xml=/news/2002/02/06/wter106.xml
  US defiant over missile defense
    http://www.globalsecurity.org/space/library/news/2001/space-010717-wwwh1j17.htm
  Bush defiant over 'Bin Laden tape'
    http://news.bbc.co.uk/1/hi/world/middle_east/3204612.stm
  Bush defiant ahead of visit to Britain
    http://fpeng.peopledaily.com.cn/200107/18/eng20010718_75285.html
  'Bring them on,' defiant Bush warns Iraqi militants
    http://seattletimes.nwsource.com/html/nationworld/135155984_iraq03.html
  Greenhouse gas emissions soar in defiant US
    http://observer.guardian.co.uk/international/story/0,6903,515198,00.html
  Europe seethes as defiant US goes its own way
    http://www.guardian.co.uk/bush/story/0,7369,747743,00.html
  Defiant US threatens UNs peacekeeping role
    http://www.abc.net.au/7.30/s596992.htm
  US isolated but defiant on Cuba sanctions
    http://www.sunsonline.org/trade/process/followup/1996/04160196.htm