Re: Parameter entities vs. GI name gro

> From: Sean Mc Grath <sean@digitome.com>
 
> Expressive power in any syntax/semantic melange comes in a variety
> of forms. Expressive power can be increased by adding
> extra *syntactic* constructs. This has been the SGML way. New concept
->
> new syntactic construct -> new parser. On the other hand,
> expressive power can be increased by allowing *existing*
syntactic/semantic
> constructs to be combined. This, as I understand it, is more like the
XML
> way.

No, I think that SGML has suffered by not having enough syntactical
constructs: it should allow you declare anything inline, in-prolog,
externally, or system-dependent, for example. Then when a particular
fashion, like WWW inlinedness ("bellbottoms"?), came along, the
unfashionable parts could be thrown out, like in-prolog declarations
("jumpsuits"?) 

I think a useful approach is to think in terms of the framework
language and
embedded, little languages:  XML-lang is the framework, and XML-link is
an
embedded language.  The simpler we make XML, the bigger people will
have to 
make their embedded languages, since the tasks people have to do won't
vary.
But people are more comfortable with series of neatly discrete embedded

languages, e.g. CSS.  

SGML had this at its core, in that it divided its declaration language
from
the instance language. (This is why I think the XML-data example is
unreadable, in that it doesn't provide a different syntax for what is a
different order of things semantically.  It is also why I think the use
of SGML-looking syntax in HyTime makes things difficult to read: you
have to fight against your existing knowledge.) Ditto with FPI embedded
language.

You could even view shortrefs as an attempt to allow the declaration of
simulated, embedded, little languages.  But people seem to want very
sharp boundaries between where the framework language and the embedded
language.
I wonder if this is part of the namespace issue, that many people don't
think of a document having a type which can be synthesized from many
element sets, rather they think of discrete languages which are
frightening if larger than
some ill-defined size.

Which is a long way of saying "if we get rid of entities people will
use some other method, because they need the functionality -- so do we
want that?"  If we do, then we should standardise a way of notating the
preprocessor used: I suggested before something like a "prepro"
attribute in the XML PI. 


Rick Jelliffe

Received on Friday, 4 July 1997 06:43:24 UTC