Re: In lieu of multiple attlists: LINK?

<david>
Yes, but it's at least _arguable_ the people agree on what
SHORTTAG means [as opposed to LINK], and how it is to be interpreted. 
</david>

<steve>
I have never felt the need to ask the question "what does LINK mean", only
"what does it do?". As to interpretation: Isn't it patently obvious that
the example I gave should be interpreted as meaning nothing more or less
than "associate the semantics of xml-link with the xref element type"?
</steve>

<david>
                            LINK introduces a whole new syntax, and is
> >widely avoided even within the SGML community (it is, of course, popular
> >with some SGML users).
</david>

Let's talk about the syntax and the design goals, and not worry about
popularity.

There are four alternatives to Steve's proposal:

>1 Play it Safe...
>2 Count on Utopian ATTLISTs...
>3 Stopgap PI...
>4 GI escape hatch...

Compare Steve's Proposal to Stopgap PI as already proposed by Paul --
which of the 10 design goals does Steve's proposal not meet? Just
possibly, (5) the number of optional features. 

But compare implementing multiple attlists using a simplified LINK to
implementing them using a hac.. stopgap PI. The first: clear syntax that
is "formal and concise" and expressible and checkable using SGML. The
second: syntax that, if formal, can only be understood by special-purpose,
non-SGML that understands what's unside the processing instruction. 

I'm not sure that's a good precedent to set. Once blessed by the XML
standard, PIs, doubtless in proprietary formats, will proliferate like
kudzu all over everything. So much for design goal 6....

<steve>
LINK just gives us a modular, extensible wrapper for the multiple attribute
definition lists everyone seems to want. The syntax is dead simple, especially
in the restricted form I suggested and there is free working software out
there that will handle it.
</steve>

Agreed!

<david>
No-one defended LINK before, and we already have 2 ways to continue
avoiding it, so why resurrect it now... 
 </david>

I'm not sure the argument from history impresses. If it meets the design
goals now, for issues we have not hitherto addressed, then what's the
problem? 

<david>
We don't need any new syntax to solve the problem we have,  so we should
>not use any, especially something as controversial as LINK.
</david>

I too am new to the list -- avoidance of controvery is a design goal for
XML?

Doesn't the PI proposal propose a new syntax -- just one that
only a special purpose tool can make use of, and that builds in theneed to
convert XML data when the "real" solution comes to be? If Steve's proposal
meets the design goals, why not use it now?

Received on Friday, 21 February 1997 16:08:18 UTC