DRAFT: Summary of ERB conference call

The following is a summary of the ERB's telephone conference of 2/19/97,
ending with a question to the WG:

We considered questions 2.1 through 2.4.

2.1.a Should we allow link recognition via a reserved attribute?

The ERB is strongly leaning to yes.

2.1.b If so, should we generalize this and say that it's an AF?
2.1.c If so, should we provide an introduction to AF's?

We achieved consensus that we should provide clear self-sufficient
documentation; readers should not have to understand the extended facilities
annex to understand what we are talking about. We should not go further: no
general introduction to AFs. We should mention at least once that it *is* an
AF; with the reference to HyTime probably.

2.1.d If we allow such recognition, what should the attribute be, and what
should be the values for each element type we define?

This remains undecided. We are leaning toward XML-Link, but the nature of
values must remain uncertain until we decide about the constructs the values
are naming. There is some thought of having xml-tlink and xml-ilink as
attributes, whose value has *all* the information we need, eg something
roughly like

  xml-tlink="url (http://www.uic.edu/orgs/tei/p3) id (foo) child (3 p)"

  (This is an illustrative example ONLY.  It is NOT a proposal.)

2.2.a Should we allow link recognition via a reserved GI?

This remains hotly in question; see below. It should be noted that the
HyTime TC introduces some of this effect by default: a GI that matches the
name of an active architectural form, defaults to being of that form.

2.2.b If so, what should the set of GI's be?

The same as the keyword values of xml-link attribute (if it has keyword
values ...)

2.3 Should we provide a PI or other signaling mechanism whereby a document
can specify that particular elements ought to be processed as link elements?

This remains unclear; see below.  If the proposed SGML TC fails for any
reason and we never have multiple attlists, this is the way to go (this
appears to be the consensus, or at least the majority view).

2.4: Should we allow that processors can decide that something is a link for
their own unspecified reasons, e.g. hardwired knowledge of their own private
element types, or external interaction?

The consensus was that we should not forbid, discourage, encourage, or
mention this more than necessary.

---

Overall:

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.  Document the magic attribute and go no further yet.  To use
it with validating systems, you'll have to monkey with the actual DTD.  XML
docs will otherwise be verbose.

After the TC passes, we'll add documentation for doing it with multiple
attlists, so you don't have to monkey with the DTD.

2 Count on Utopian ATTLISTs.  Document the magic attribute *and* the use of
multiple attlists.  After the TC passes, XML will be kosher.  Until it
passes, it's non-conforming (although individual documents can choose to be
SGML-conformant or not).  If the TC fails, we have to go back and add a PI.

3 Stopgap PI.  If we can't stand the verbosity of Playing it Safe, and can't
risk counting on Utopian ATTLISTs, we need a stopgap. The simplest seems to
be to define a PI for the necessary function, e.g.

  <?ATTLIST xref xml-link CDATA 'xml-tlink'  ?>

or

  <?xml-attlist xref xml-link cdata 'xml-tlink' ?>

In the short term, we have no verbosity problems.  In the long term, after
the TC passes, we withdraw the PI and use only multiple attlists.
If the TC fails, we change nothing.

Drawbacks:  planned obsolescence of this syntax may be hard to enforce.
Once we have XML legacy data, removing the PI in version 2 may be hard.
(Of course, xml link won't be *final* until november or so, we should know
by then.  Until November, we should -- by definition -- not have legacy
data.  All xml data made before then is experimental and has no claim on our
protection.)

4 GI escape hatch.  Like playing it safe, but to avoid the verbosity problem
we at least allow GIs to be recognized.  so in the long term you can be
terse with multiple attlists; in the short term, by using magic gis.

The ERB requests that the WG consider the question of how best to deal with
this signalling issue, given the options and tradeoffs (and any others the
WG may perceive).

Steve
(with copious thanks to Michael and his notes)

Received on Thursday, 20 February 1997 18:43:54 UTC