Re: Shortrefs fatally flawed

>>I think we can pick a name that is highly likely not to be used.
>It must still be a special name, and explicitly documented, and (possibly)
>part of the application interface (where explaining XYZZY elements will be,
>at the least, picturesque).
>
>And if I generate tags by some automated process (say for distinct
>formatting styles in a document coversion product) I might come up with the
>"unlikely name" as a result of an algorithm. (base-26 encoded integers,
>anyone).
>
>This is a fragile, arbitrary, and ugly-to-describe "solution".

Agreed. I cannot see why getting rid of RE/RS is such a problem. The
rule is then simply "If you put them in, they're there". So far, I
haven't seen a good *technical* justification for it except that of
SGML tool compatability.... and now we're talking of using features of
SGML that are not widely implemented, or of converters, I can't see
why that is any better than the "no RE" proposal.

In the long run, we're just describing an attributed tree (or a list
of lists). Why is it so hard to describe it? The syntax should be
dead simple, and the rest just semantic interpretation of the data
structure built from parsing the description. Even the node names are
often irrelevant except as an aid to later semantic interpretation,
and we even have a framework for decoupling that link as well.

I guess you could say that I'm thinking about people thinking about
burgling a house....

Received on Wednesday, 2 October 1996 13:40:24 UTC