Re: DRAFT: Summary of ERB conference call

> From: "Steven J. DeRose" <sjd@ebt.com>
> The following is a summary of the ERB's telephone conference of 2/19/97,
> ending with a question to the WG:

> We think we can have multiple attlists when the TC passes. It's not clear
> what to do in the meantime. Choices include:

> 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.)

> 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).

I like the so-called "Stopgap PI" with content that looks just like an
attlist would.  I don't see the "legacy" problem as very problematic.

Before the TC passes, you must have:

   <!DOCTYPE tei.2 public "-//TEI//DTD P3//EN" [
   <?ATTLIST xref
             xml-link    CDATA   #fixed "xml-tlink" ?>

and after it passes, you can still have the above or you can have

   <!DOCTYPE tei.2 public "-//TEI//DTD P3//EN" [
   <!ATTLIST xref
             xml-link    CDATA   #fixed "xml-tlink" >

with the latter form preferred.  Why care about enforcing obsolescence?
That would be like getting upset that people still use ISO 8879-1986
instead of ISO 8879:1986 in FPIs.