Re: ERB decisions on the LINKTYPE proposal

"David Durand" <dgd@cs.bu.edu>
> >The particular usage of LINK that led me earlier to propose its inclusion in
> >XML is the same one as for HTML: attaching SDA attributes to a document
> >instance for transformation to the ICADD DTD. The added features of LINK
> over >the proposed alternative ATTLIST solution (context-sensitive
> processing for >one) make me question why ATTLIST is even considered -- they
> are not a direct >match functionally.
> 
> The disadvantage is that the attributes are not "real" attributes, but are
> attributes in some "result document". This creates confusion when you have
> two attributes with the same name and different values. We need not even
> open that can of worms if we stay away from link...

Sometimes I feel like I'm just sitting on a different planet, not necessarily
Earth. The whole point of any transformation process, whether it be DTD to DTD
or adding presentational information from a stylesheet, is to begin with one
document and end with another. There is a source document and a result
document. Yes, they may contain like-named elements and attributes. Why in the
world this would be confusing is beyond me.

[...]
> >I agree completely (except when the document is part of a transform
> >process).
> 
> No, just never. The transform process is a separate thing, and should be
> stored separately.

I was not clear. There is a source document. There are [possibly] intermediate
documents. And there is a result document. Some of these intermediate
documents are stored permanently, some not. By design. A transformation
process by definition.
 
> >I still don't understand why there isn't more screaming about some of the
> >extensive proposed XML uses of PIs. I find PIs as abhorrent as some do LPDs.
>  I agree, but I decided that since I lost the battle against PIs, that I
> could rationalize XML PIs (only) as not too evil, since they have a defined
> semantics, and take advantage of the only syntactic extension hook we have.
> This latter is only a need because we opted for syntactic compatibility
> with DTDs rather than instance syntax.
> 
> The thought that users (and Netscape and MS) can make their own PIs still
> makes me very nervous...

This is the reason I don't want to see XML define link semantics that show up
in the instance, specifically as PIs or as an agreed-upon set of attribute
values. This was IMO one failure of the HTML REL/REV proposal: defining some
portion of an attribute namespace. If we take either the PI or attribute value
approach, once we see a completely i18n'd SGML and accompanying tools, Chinese
authors can write XML instances using Chinese, *except* for the links that
show up as something akin to

I do believe we should agree on a minimal set of link behaviours, and define
names for those behaviors in English. It is, after all, the language of the
specification. But we need an indirection mechanism to abstract the link names
so that Chinese documents won't need to include 'toc', 'previous', 'next',
etc. which may have no meaning to them. This (from what I can gather) would be
necessary if we used the PI or attribute namespace solution.

> >Use of LINK doesn't require processing information be embedded in the
> >document instance, which is precisely one of its benefits. The alternative
> >proposed ICADD solution of using multiple ATTLISTs *does* require adding
> >the ATTLIST declaration to the declaration subset, which I find less
> >desireable for precisely the reason you state above.
> 
> I don't know from ICADD. The lack of multiple attlist delcarations is a
> continual thorn in the side of DTD authoring, well worthy on its own merits
> -- Once we have it, though, we no longer need another way to allow people
> to attach atributes to elements in documents.
>
> It's not the acme of elegance, but it uses no new syntax, no new semantics
> of output processing and LINK attributes, and has all the power that we
> need (as does IMPLICIT LINK).

If you don't want the same processing for elements in differing contexts,
ATTLISTs won't do it for you. As I mentioned before, ATTLISTs don't provide
context-sensitive mapping, so it's only a partial solution.

[time passes.] OK. I've just received a copy of the discussion leading up to
this, so some of the questions and confusion falls away.

From what I can see, we are trying to provide an indirection mechanism for
XML-LINK so that specific XML applications can tie their particular link
elements to XML link elements. I believe this message comes from before Steve
Pepper's LINKTYPE proposal was added as #5:

At 21:08 20.02.97 +0100, Steve DeRose wrote:
>We almost all agree that the best long-term solution is to allow multiple
>ATTLIST decls, so a document can start
>
>   <!DOCTYPE tei.2 public "-//TEI//DTD P3//EN" [
>   <!ATTLIST xref
>             xml-link    CDATA   #fixed "xml-tlink" >
>   ]>
>
>This documents that the tei element <xref> is a tlink in XML terms.
>
>We think we can have multiple attlists when the TC passes. It's not clear
>what to do in the meantime. Choices include:
>
>1 Play it Safe...
>2 Count on Utopian ATTLISTs...
>3 Stopgap PI...
>4 GI escape hatch...

so we add

 5 LINKTYPE

which is 100% SGML compatible and available now.

You said:
>    Anyway, Jon said that LINK will only be considered if multiple ATTLISTs
> fail. so let's just give this a rest, or take it off the list.

I'm not sure where this declaration comes from, but I don't understand it out
of context. I believe the purpose of discussion is to locate the best
solution, and apart from political arguments that I don't agree with,
discussion of LINK as a possible solution seems within bounds.

So where are we?

1. Play it safe...
I don't know what Steve is meaning here, but I'm assuming nothing. If I did
assume he meant a fixed attribute like XML-LINK, fine. I have no problem with
that solution at all. I don't think that as an option is bad at all, but I
want something better, something with indirection so that the GI can be mapped
in the prologue rather than the instance.

2. Utopian ATTLISTs
I imagine that multiple ATTLISTs will pass in the TC, but I find the fervent
pointing to that as a solution just as fanatical as myself believing LINK is
viable. They are not the same solution, and there are advantages of LINK over
multiple ATTLISTs: for one, context sensitivity.

I believe "design elegance" also applies here. From a purely human-readable
context, if I want to point to a generalized mechanism for 1) transforming
HTML to ICADD or 2) providing linkage between an XML application and XML-LINK,
I can point to an LPD that is somewhat self-contained, and from appearance is
a pretty good mapping between the set of GIs and attributes and what will
happen to them in the transformation process. By contrast, the ATTLIST
document is simply an addendum to an existing DTD, so one must have the DTD,
and sit down and figure out (given all sorts of parameter entity indirection
that shows up in many DTDs) where the ATTLISTs will be applied and in what
context. By contrast, the context is set in the LPD so it's easier to see. For
simple ATTLISTs, this is obviously not a problem.

3. Stopgap PI...
Ugly at best, and requires authors to do precisely what many of us detest: add
processing-specific material to our documents.

4. GI escape hatch...
This is not much of a solution for XML versions of existing DTDs, nor for
those who don't want their markup in strict XML GIs.

and finally,

5. Steve Pepper's idea [Date: Fri, 21 Feb 1997 12:43:16 +0100] of specifying a
restricted subset of SGML implicit links is fine by me -- this is probably
obvious to those I've discussed this with before. His restrictions reduce the
implementation burden substantially, especially when considering that the
alternatives are either multiple ATTLISTs (not yet allowed, not guaranteed to
be allowed, more difficult to human-read without a DTD for context, and no
context-sensitivity) or a DSSSL transformation engine. Just in terms of
complexity and footprint, I can't imagine requiring a DSSSL engine merely to
use XML-LINK. 

My only change would be:

> 1. Only one link type declaration is allowed. It must be called
>    "xml-link" and it is by definition an "active" link type for an
>    XML application.

For purposes of ICADD transformation, this restriction would disallow
transformation via LPD of any XML instance that already was using an LPD for
link indirection. The restriction could be 'only one link type declaration of
the same link type', so two LINKTYPEs would still be disallowed.

Removing all the 'unnecessary' stuff from SGML is what XML is all about.
Removing the unnecessary stuff from LINK might warrant its inclusion in XML,
and I believe provide a much simpler method than a DSSSL engine for certain
processes.

Murray

----------------------------------------------------------------------
Murray Altheim, SGML Toolhead                    <altheim@eng.sun.com>
Tools Development & Online Production
Sun Microsystems, Inc.
Menlo Park, California

Received on Wednesday, 5 March 1997 18:41:17 UTC