[tei-council] open issues and planning

[Syd Bauman]

This date attribute stuff is turning out to be a pain in the neck, so
only a very hasty few issues here:

* On our "commitment":
  I probably missed something, then. I thought we were quite careful
  at the MM in Victoria *not* to make a full-fledged commitment to
  have P5 done by College Park. Especially with the Board and meeting
  committees not sure if they want to have a 'P5 release' event in
  Taiwan or not, I thought it was deliberate. Besides, Lou has
  suggested, and I think he's right, that an additional face-to-face
  meeting over chapter review is probably a good idea. That may (or
  may not) make it quite difficult to be done with 1.0 by MM2007.

* On "frozen":
  Perhaps Sebastian & I are simply using different definitions,
  perhaps we completely disagree. Here's my basic take on the deal.
  - "frozen" means r/o, and is a drastic step that is taken
    immediately before publication
  - none of P5 is currently frozen
  - much of it is close -- I like the word SR used "gelid"
  - I would guess some 95% of or Spec files are gelid, with a bunch
    that are due for significant work, including (off the top of my
    head) those affected by:
    + changes to dating attrs
    + limited-phrase decisions
    + handling regularization of names
    + handling spans
    + implementation of feature requests
    + whatever we end up doing about postscripts
    + new stuff on "placeography"
    + addition of Schematron rules
    + the div0, div1, div0|div1, or no numbered divs decision
    + potential changes to bibl, biblStruct, biblItem system
  - I see that others have different takes on the definition of
    "frozen" and such, and I am not at all insisting that we use
    mine; but I wanted you to know where I was coming from and my
    take on all this

* On feature requests and <choice>:
  I do not think Daniel's idea is a bug-fix request at all, but a
  feature request. I think we've already made two calls for feature
  requests with cut-off dates, and we should *not* make a third. That
  does not mean we should stop considering user input (e.g., bug
  reports like "neither <add> nor <note> is not allowed between
  <div>s"), but that we should not be considering new feature
  requests (like making <div> a permissible child of <choice>). I
  realize that in some cases there is a fine line between the two,
  and room for disagreement, discussion, etc. But that doesn't change
  my basic premise.