Of course, then there's the question of how efficient the w3 code is.

[*] Says the man who writes his papers using Emacs and LaTeX on Unix ;)
On the other hand, MS Word users never hear, "I really liked your
exposition of such-and-such a point in this paper ... and it's so
*pretty*, what did you write it in?"

The Cartoon Guide to Statistics
Larry Gonick and Woollcott Smith
Harperparennial, 1993.
        [probably one of the finest books on statistics ever written
        and i even own a first edition freedman/pisani/purves...]

The Complete Idiot's Guide to Publishing Science Fiction
Cory Doctorow and Karl Schroeder
Alpha Books, 2000
        [a very sharp, must-read book on becoming an SF writer and
        publishing what you write.]

[nothing in my CS shelves jump at me right now, though i think meyer's
2nd ed may have given a fluffier impression to an innocent browser than
it actually is. on the other side, hopcroft/motwani/ullman "introduction
to automata theory [etc]" is a money-making exercise with much reduced
theory literacy and should be avoided while holding nose...]

Thank you! That was exactly the sort of terse overview I was hoping for.

+---------------
| Things that the SGML community think are important, but which only
| detract from the real issues and confuse people tremendously:
|
| · attributes to elements, notations, entities.
| · attribute types
+---------------

Well, this list has certainly talked about *that* one enough before.  ;-}
Clearly, since a DTD can specify that some subset of sub-elements (in
arbitrary order) *must* come before all the other permitted sub-elements,
then "attributes" could just as easily be expressed as sub-elements
with restrictions on order, much like declarations and documentation
strings in CL, yes?

+---------------
| | ...verbose way of externally representing (serializing) trees
| | (though not DAGs or more complex structures), and which S-exprs
| | do a much better job of (especially if you allow "#n=" & "#n#" ...)
|
| The rank incompetence of SGML and XML aficionados has led people to believe
| that the syntax cannot represent anything more complex than simple trees.
| This is just as wrong as claiming that Common Lisp cannot express circular
| lists and other forms of reused objects to preserve identity throughout the
| printed form of a structured.  Using ID and IDREF is exactly analogous to
| using #n= and #n#.
+---------------

Aha! That's what I get for not having read the actual SGML specs, I guess.

+---------------
| (And just as they have special syntax in Common Lisp, they should have
| special syntax in an attribute-free SGML.  It is the only thing that
| /needs/ attributes in the SGML syntax.)
+---------------

I need to think about that one a bit more (and maybe go read some more).
At the moment, it's certainly plausible to me that IDREF might need
special syntax, but it seems like one might to be able to provide ID
(albeit rather awkwardly!) with attribute-free elements [as above].

Anyway, thanks again for the concise summary,

-Rob

    (idl-files
     (:name "f1"
      ...)
     ...)

And lo and behold this ends up as something like:

    (let ((m (make-instance 'idl-files :name "f1" ...)))
      (loop for b in body
            do (add-item-for m b))
      m)

(in fact it's a lot more complex than this, but this is the idea).

So of course the `natural' XML version of this is:

    <idl-files name="f1">...</idl-files>

So people complained bitterly when we did this as:

    <idl-files>
     <parameters>
      <parameter>...</parameter>
      ...
     </parameters>
     ...
    </idl-files>

So why did we do it like that?  Because XML attributes can't have
structured data, so if you want, say, a list of things in an
attribute, you have to write your own little parser, oh joy.  And (not
in the examples above) we *do* have structured data.

What we ended up with was a hack that looked for XML attributes and
translated them to parameters with stringy values.

  Happy to oblige, but I think I should whip up a web page on this now that
  I think I got it reasonably right.  The standing-on-one-leg stunt is hard.

| Clearly, since a DTD can specify that some subset of sub-elements (in
| arbitrary order) *must* come before all the other permitted sub-elements,
| then "attributes" could just as easily be expressed as sub-elements with
| restrictions on order, much like declarations and documentation strings
| in CL, yes?

  There is a crucial difference between attributes and subelements today
  that needs to be taken care of in an attribute-free SGML.  Attributes are
  local to their element and therefore can be the same name as an element.
  They could also differ in type from element to element, which translates
  to a different content model or notation as an element.

| | Using ID and IDREF is exactly analogous to using #n= and #n#.
|
| Aha! That's what I get for not having read the actual SGML specs, I guess.

  But you may need to know #n= and #n# and that they are analogous to see
  this because the application gets to maintain its own table of IDs and
  map the IDREFs back to them, which is kind of unfortunate.  Grasping that
  this can be used for circular structures is apparently hard for SGMLers
  when they have only learned to think of them in "See Figure 1" terms.

| I need to think about that one a bit more (and maybe go read some more).
| At the moment, it's certainly plausible to me that IDREF might need
| special syntax, but it seems like one might to be able to provide ID
| (albeit rather awkwardly!) with attribute-free elements [as above].

  One curious effect of moving from attributes to elements is that quite
  often, the best design is to let the attribute become a superelement
  instead of a subelement.

--
Erik Naggum, Oslo, Norway

Good point. And also, as Tim Bradshaw pointed out in a parallel
reply <URL:news:ey3u1k6uyv1.fsf@cley.com>, attributes are not
permitted to have sub-structure[1], while sub-elements may.

[1] Well, not *standard*, DTD-defined sub-structure, that is, though
    as Tim noted, one can always hack up an ad-hoc serialization of
    the sub-structure into the string value of an attribute...  (*ugh!*)

+---------------
| | | Using ID and IDREF is exactly analogous to using #n= and #n#.
| |
| | Aha! That's what I get for not having read the actual SGML specs, I guess.
|
| But you may need to know #n= and #n# and that they are analogous to see
| this because the application gets to maintain its own table of IDs and
| map the IDREFs back to them, which is kind of unfortunate.
+---------------

Do you mean that the application is allowed to merge (remapping as needed)
IDs/IDREFs from *multiple* documents? ...or *across* multiple docs?
[Otherwise I don't see where any "table" or "mapping" is needed, other
than just the one necessary for #n=/#n# processing during the READ.]

Hmmm... The corresponding thing in CL might be trying to reference the
same #n=/#n# numbers across multiple occurrences of READ. Normally,
that wouldn't be a problem (because it's not possible), but my twisted
little brain just started wondering about how #n= & #n# might interact
with #. in pathological cases, as in:

        (foo #1=bar #.(read-from-string "(a #1=b c #1# d)") gorp #1# blah)

Well, maybe that's not a good example -- both CLISP & CMUCL handle it,
yielding (FOO BAR (A B C B D) GORP BAR BLAH) -- but *this* one, maybe:

        #1=(foo bar #.(read-from-string "#1=(a b c #1# d)") gorp #1# blah)

CLISP handles it this way [assuming (setq *print-circle* t), else it
core-dumps]:

        > '#1=(foo bar #.(read-from-string "#1=(a b c #1# d)") gorp #1# blah)
        #1=(FOO BAR #2=(A B C #2# D) GORP #1# BLAH)
        >

While CMUCL complains:

        Reader error at 3 on #<String-Input Stream>:
        Multiply defined label: #1=

O.k., CLHS "2.4.8.15 Sharpsign Equal-Sign" says:

        The scope of the label is the expression being read by the
        outermost call to read; within this expression, the same label
        may not appear twice.

So perhaps in CLISP's case the READ-FROM-STRING instance causes a
completely different instance of READ (and thus the two #1= aren't
"the same") and in CMUCL's case READ-FROM-STRING "knows" it's inside
an active READ and (legitmately) tosses an error.

But then why does CMUCL *accept* the first form at all?!? They both
have the same "outermost call to read"...

+---------------
| Grasping that this can be used for circular structures is apparently
| hard for SGMLers when they have only learned to think of them in
| "See Figure 1" terms.
+---------------

*ROTFLMAO!*  Yes, I know what you mean, but... Does "See Figure 1"
have the same alternate meaning for you guys over there as it does
around here?!?  ;-}  ;-}

        <URL:http://www.tuxedo.org/~esr/jargon/html/entry/See-figure-1.html>
        <URL:http://www.things.org/~jym/fun/see-figure-1.html>

+---------------
| | I need to think about that one a bit more (and maybe go read some more).
| | At the moment, it's certainly plausible to me that IDREF might need
| | special syntax, but it seems like one might to be able to provide ID
| | (albeit rather awkwardly!) with attribute-free elements [as above].
|
| One curious effect of moving from attributes to elements is that quite
| often, the best design is to let the attribute become a superelement
| instead of a subelement.
+---------------

Yeah, I was starting to think in that direction, since it reduces the
number of levels of nesting you need in the common case of only one
attribute. It's much like CL WITH-XXX macros, in that way. (And why
am I suddenly thinking of CLOS "around" methods, too? ;-} )

-Rob

Edwin is "sufficiently complete" that it will read your existing Info
configuration, and can browse Info files.

There does not appear to be any guide to writing extensions.

<http://www.cs.colorado.edu/~main/manuals/scheme/user_66.html>

Missing Subsystems

The following documented subsystems are implemented by Emacs but not
by Edwin.

    * abbrev mode (edwin has dynamic abbreviations)
    * emulation modes: edt, vi, vip
    * file locks
    * language modes: emacs-lisp, fortran, lisp, modula-2, prolog
    * overwrite mode
    * picture mode
    * slow terminal incremental search
    * spelling
    * tab stops
    * text formatter modes: nroff, scribe, tex, latex

In the 70s, I had a negative reaction to software that tried to be all
things to all people. Every system I looked at had its own universal
Turing machine built into it somehow, and everybody's machine was a
little different from everybody else's. So I thought, "Well, I'm not
going to design a programming language; I want to have just a
typesetting language." Little by little, however, I needed more
features and so the programming constructs grew. Guy Steele began
lobbying for more capabilities early on, and I put many such things
into the second version of TeX, TeX82, because of his urging.

  Well, actually, you can provide a NOTATION argument for attribute values.
  This would indicate the standard or other document specifying the syntax
  of the value, and the application would presumably know how to deal with
  this.  Also, there are actually some attribute types that require a flat
  list of whitespace-separated values in the actually attribute value.

| Do you mean that the application is allowed to merge (remapping as
| needed) IDs/IDREFs from *multiple* documents? ...or *across* multiple
| docs?

  ID and IDREF have many conflated uses.  IDREF can only refer to IDs in
  the same document instance, but with other mechanisms, you can refer to
  elements with a given ID.

| The corresponding thing in CL might be trying to reference the same
| #n=/#n# numbers across multiple occurrences of READ. Normally, that
| wouldn't be a problem (because it's not possible), but my twisted little
| brain just started wondering about how #n= & #n# might interact with
| #. in pathological cases, as in:

  I would have thought it fairly obvious that (list #.(foo #1=bar) #1#)
  must fail, and it did not appear any less obvious that (list #1=foo
  #.(foo #1#)) must fail.  However, this is wrong.  They work fine in
  Allegro CL, CLISP and CMUCL (and SBCL).  Hmm.

  However, when you call a `read´ function without a true `recursive-p´
  argument, that should mean that it establishes a new #n# context.

| +---------------
| | Grasping that this can be used for circular structures is apparently
| | hard for SGMLers when they have only learned to think of them in
| | "See Figure 1" terms.
| +---------------
|
| *ROTFLMAO!*  Yes, I know what you mean, but... Does "See Figure 1"
| have the same alternate meaning for you guys over there as it does
| around here?!?  ;-}  ;-}

  Yes, and it was intentional.  (I always appreciate it when people "get"
  such jokes.)  I initially wrote "See Chapter 42" but that was hackneyed
  and not entertaining at all.

--
Erik Naggum, Oslo, Norway

Does anyone recall this CL browser?  Anyone ever use it?

www.uni-karlsruhe.de/~unk6/closure/

-dan

--

Of course, this is emacs we're talking about, so the argument for
doing it in this inside-out fashion is usually more compelling.  It
isn't the text editor as such you want to embed in, it's the rich
dynamic environment (GC, runtime typing, interactive evaluation) which
is (a) better than anything Unix typically offers, (b) rather too
"heavyweight" to blithely embed into another application without
feeling some twinge of guilt.  And of course, (c) allows you to edit
text with _all_ your favourite gestures (a curse on whichever Mozilla
developer thought it would be funny to support C-k but not C-y ...)

In this specific case, though, we're talking about a Lisp app as the
other partner in this symbiosis.  Closure runs in a _really_ rich (and
heavyweight) dynamic environment with generational GC, threading, CLX,
CLIM, etc (I believe that the McCLIM text editing component is
destined to end up looking pretty emacsy).  So all I'm saying, really,
is "let's pause for a minute to consider which component is on top in
this relationship"

-dan

--