None, this electronic version is the original.
Meeting, hosted by the
Commenced a bit late at ~10:50 due to bus delay ostensibly due to weather, with SB, LB, AB, JH, CR, NS, JW, SS, SW, TE.
The Chair and local host worked out a few schedule changes accordingly.
Group extends a warm and heartfelt thank-you
to AB and the Cervantes project
for hosting this meeting.
Question of whether or not we need our own version control system for the group. We have already suffered at least one failure (two people writing to the same file). LB doesn't think we need to, as there should always be only a two-way communication between author & technical writer (SW), and then technical writer & editors.
Process editors use to update TEI depot and website explained.
CR suggests the following work flow:
For this meeting, SW will make changes, website will be updated afterwords.
1.5 is the public version that contains some of JH's changes. New changes (since last meeting) have been checked in by JH, but (at request of OpenJade team) to two different branches, thus very difficult to even build it via CVS (and there are no tarballs, let alone binaries).
Consensus is that our documents need to be out before we can be assured that OpenJade will update osx, so we will plan on including migration steps that hack around OpenSP 1.5 limitations, but footnote them as not needed iff new version of osx is available.
Agreed to put any available binaries we have (cygwin or Mac OS X or whatever) on
publicly available website. Consensus of group is that we have done what we
reasonably could to get a Windows binary; we don't have access to the programming
expertise needed, and on the theory that small projects can use the web interface,
any larger project will have GNU/Linux or at least cygwin capability, we're going to
all but stop trying.
Thus, we can establish deadlines by working backwards from that date.
Currently authors have ownership of case studies.
CR raises issue that MI W 02 and MI W 03 have quite a bit of overlap — general agreement that there will be some parallel and coverage redundancy, but to continue policy of general overview for MI W 02 and details in MI W 03. Specifically CR's nice table on osx switches should be moved from MI W 02 to MI W 03.
Editors concede that they need to write their section. Editors solicited input as to
what should be in this section, and were given the following items:
I.e., what you have now is dead, what is coming is even better.
Missing sections:
Consensus not to request MI W 06 section from TR.
It was agreed that we need a consistent terminology of migrations.
Agreed to remove casual terminology, not address reader as you
, and to refer
to this task force as we
.
Agreed that readers should see titles, although reminder to authors to please encode
with an
SS & CR to take a crack at re-writing.
CR lists motivations as (in order):
On the topic of open source tools we decided that MI W 02 should simply point to
TEI Software page. But the list of X- standards should be expanded
Suggested re-write of para 1 sentences 2-4 of Motivation section to SS, who will
re-write and post.
After a bit of discussion on the implications of standards
it was agreed to
change standards
to standards and specifications
.
The point of the
Concern (SB & CR) that we have too many internal references. Consensus was that they're a good thing, but that after we've assembled documents into a whole we need to look over and see if there are too many.
At lunch SS & JH …
Add mention of if old DTD via chef, make new one
.
Add sentence at end of DTD section that DTD extensions can be hard, whereas many will find instances easy. Include explicit pointer to section of MI W 03.
Catalog file section to mention that entity conversion is a pain. Decided to put this under processing environment. JH asks about XML catalog syntax. Consensus is that we will provide a pointer to further info. If software is available at the time, we'll mention it.
JH to later the "by ahnd" phrase.
Processing environment: XML tools more likely to stop at first error; more detail about delivery environment including index tools, web output generation stuff
SS is concerned over discrepancy between "is straightforward" (instance section) and TR's list (MI W 04). JH to change to can be straightforward.
List of editors: disagreement among group, but in the end we decided that a
disclaimer you need to think about choosing your editor carefully, but we're
not talking about particular editors
probably with a pointer to somewhere
that discusses this stuff.
We decided the wording of Target production environment
was a bit too
strong — while projects should consider production environment first, it may be
too much to actually have it running first.
The subsection on Training, once the tools discussion is removed, is pretty short, and therefore will be rolled into the Resources section.
Replace language of 2nd para of
Changes to final para of
Suggestion that the data testing rule of thumb 1, 10, 100%
be used.
Add item to list in
design and run test procedures.
Table of switches moves to MI W 03.
Question of whether a comment is a declaration or not arose — answer is that in
SGML they are called comment declarations
while in XML they are comments
--
and the <!
or >
,
and the whole thing is called a comment
.)
Consensus was that we should recommend use of the -xpreserve-case and
Large discussion on what it means to be a robust conversion; then all conversion categories. Agreed to eliminate the explicit distinction into easy, minimally invasive, robust.
Discussion of ESIS — decided to eliminate reference to jargon here.
Discussion of being more generic than mentioning osx specifically.
supra-validationat the meeting, but I needed some way to refer to it here in the minutes, and that's what we call it at the WWP. Feel free to suggest another term.
JH suggests (and no objections raised) that a new paragraph or section about the various possible pitfalls of migration (including errors created by migration scripts, some of which might not be caught by validation) be added to MI W 03. And in the
Comments are for the author, should be removed before we make the files public. If
author wants to send commentary to the rest of the group uses
CR is suggesting outline:
SS & CR to re-work intro to MI W 03 to make it more parallel to the intro of MI W 02.
Question of XMetal as tool was raised —
Discussion of tei2tei.xsl — we'll be discussing it as an example, not a full tool.
With respect to osx, group recommends JH put in a footnote referring to soon-to-be-available features, which could then be changed to a paragraph quickly if in fact the new version is released in time.
Decided to either not mention Notetab at all or in a general sentence in workflow about using editors as a happy front end.
Long discussion on DTDs: point made (JH) that we don't migrate the TEI DTD, we just need to tell people how to go get the new one.
Workflow section to two subsections: Intro, DTDs (w/ pointer to extensions section), catalogs, bulk on instances, processing environment.
Open SX
to OpenSP
;
Actual flow of steps (currently under Document migration
) needs to be
altered to something like:
… likely workflow that integrates all of the steps above.
At LB's suggestion the bash script in
Not a lot to say now. SW to copy-edit and repost to list
Not much to say now; v. good section, although it outweighs all the others by
several pages. Discussion of whether or not we should ditch