Semi-transparent Syntax Extensions (was Re: SD5 - Namespaces)

On Thu, 22 May 1997, Arjun Ray wrote:

> As a counter-proposal, how about adding a character to the LCNMSTRT and
> UCNMSTRT sets? For instance, '_'. Now any element name beginning with this
> character can by convention be interpreted as "namespace-qualified" where
> the namespace(s) are in some attribute value -- with a special attribute
> name: "_"!

(I get the feeling I'm opening a huge can of worms here.)

Just to clarify the "point" of this suggestion:

Working within the syntactic constraints of ISO 8879 seems to imply that
fundamentally new syntactic categories (with "semantic" significance only
to XML) aren't really possible. It occurred to me that this need not be
so. The extensibility of the namestart sets is a loophole.

Consider a candidate character, say ':' (seems to be the current
favorite:-)), and how a SGML parser would treat the string "<:FOO>" 

     '<'    is MDO
     ':FOO' is the GI   
     '>'    is TAGC

But *XML* isn't necessarily restricted to this particular parse. It could
interpret the string "<:FOO>" according to an instantiation of its own
(extended) set of abstract delimiters

   <:FOO> =  '<:' + 'FOO' + '>'

where '<:' is the binding of a new abstract delimiter. If the rest of the
surface structure is undisturbed, we can break away from the simple
containment relation implied by the SGML parse, while remaining
transparent (or should we say forward compatible?) to SGML systems. The
benefit here is mainly from the extra character (relative to RCS SGML)
being in a fixed position in the name, to which conventions can be bound
in the XML specs. 

(I can think of uses for attribute names starting with the extra
character, besides the special case of just the extra character to denote
a different kind or type of "attribute specification". And, of course,
more than one such magic character is possible!) 


FWIW, I would prefer a way to indicate namespaces via attribute trickery,
because down the road I can see somebody discovering the need to
accomodate name-sharing across name-spaces and thus a way to specify more
than one name-space as "simultaneously active". The CONCUR syntax allows
this, as does Eliot's suggestion to use architectures (if I've understood
that correctly), but a construction like 'name-space:gi' doesn't.


Arjun

Received on Friday, 23 May 1997 01:15:39 UTC