------------------------------------------------------------------------ Since this meeting, Professor Mamrak has resigned as chair of the Metalanguage Working Committee. The Steering Committee will appoint a replacement within a short time, but I thought it would be worthwhile to get these minutes out while the meeting is still reasonably fresh in all our memories. Lou Burnard 10 jul 89 ------------------------------------------------------------------------ TEI Document no ML-M-6 15 June 1989 Minutes of the first meeting of the Metalanguage and Syntax Working Committee of the Text Encoding Initative Held at the University of Toronto, Monday 4 June 1989 Present: Sandra Mamrak (SM), chair; David Barnard (DB); Lou Burnard (LB); Roberto Cencioni (RC); Jean-Pierre Gaspart (JPG); Nancy Ide (NI); Michael Sperberg-McQueen (MSM). Introductory discussion SM welcomed the committee members and tabled a summary of points for discussion, arising out of documents circulated previously. Those present briefly introduced themselves and their areas of expertise. A wide-ranging exploratory discussion concerned with the purpose of the Guidelines ensued, briefly summarised here. RC introduced the notion of an "application profile", that is, an internally consistent set of definitions arranged in self- contained hierarchic layers as a way of dealing with the wide range of requirements anticipated from the other working committees (WCs). SM saw the role of the committee as interacting with the other WCs which would themselves produce application- specific DTDs. NI stated that the TEI editors would need to factor out common elements from these DTDs. MSM suggested that the TEI could alternatively propose a 'syntax picking list'; JPG that the committee should be prepared to create and maintain libraries of syntax definitions, entity repertoires and dtds. RC was concerned that WCs would be overwhelmed without some way of structuring their tagsets. MSM observed that some mechanism was needed capable of combining different views of items at the same hierarchic level and enforcing any compatibility rules that might be defined. JPG stated that this was a semantic issue; SM that it was application dependent. JPG stated that the nesting of theories should not be embodied in syntax rules; DB that this could not in any case be checked, as the DTD-definer's assumptions would not necessarily be apparent. It was agreed that CONCUR, SUBDOC and #CONREF provided useful ways of combining DTDs into an application profile, and that the core-plus-extensions approach would necessitate some sort of 'include' type facility. It was also agreed that the primary purpose of the application- dependent software for which the guidelines were envisaged would be data interchange, and that optimisation would not be an issue. Document database SM's proposal for a TEI "document database" to contain instances of DTD applications was discussed. DB and others felt that the task of certifying DTD instances might prove too much in addition to the committee's existing tasks. MSM and SM agreed that it should be deferred. Committee ground rules o Committee procedure in the event of dissension was discussed. It was agreed to follow the usual practices e.g. of ANSI and ISO committees, where committee decisions and opinions are distinguished from those of individual members. It was agreed that a two-thirds majority of the membership was needed before documents etc. could be agreed as adopted by the committee. Documents agreed in this way would be passed to the editors, who would submit them to the Steering Committee, which would then pass them to the Advisory Board for endorsement. Some concern being expressed about the varying backgrounds and expertise of voting members, NI urged members to abstain from voting on issues on which they did not feel themselves competent. o MSM introduced the TEI document numbering scheme. Each document produced by the committee should be allocated a sequential number by the Chair. It should have a prefix indicating the committee from which it came (ML in this case) and its type (e.g. D for draft, M for minutes etc.). Document TEI-A-1 lists available document codes. o It was noted that a list of all committee documents would be centrally held (on the TEI-L server at UICVM) but only drafts accepted by the committee would be generally available. Other documents would be circulated by the Chair. It was requested that any generally available files contain descriptive markup, e.g. GML or LaTex. o A bibliography on the subject of SGML was felt to be useful. DB volunteered to take any existing lists and combine and extend them. o MSM explained the current budgetary arrangements. Up to 50% of travel expenses and a small per diem would be reiumbursed. All receipts etc. should be sent to MSM. o The Committee should be able to report by June 1990. Meetings were tentatively planned for 25th - 27th October in Luxembourg (RC to arrange) and mid-February 1989, probably in Chicago (MSM to arrange). Discussion of Draft Recommendations The document tabled by SM contained six specific recommendations, which were discussed and voted on during the remainder of the meeting. o * We recommend that instances of DRTDs be developed using a software environment specifically designed for this purpose.... * The committee agreed with the sense of this recommendation but felt that it was tactically inappropriate to begin the document with it. It was felt that a better begining would be to stress the importance of interchange in determining the recommendations which were to follow. RC asked what types of text were envisioned. NI quoted the Poughkeepsie statement that the guidelines should focus on "extended natural discourse", possibly extended to include dictionaries. RC volunteered to redraft this first recommendation. o * We recommend that DTDs be developed using a software environment specifically designed .... * This was agreed. o * We recommend that the DTD definer use none of the minimization features SHORTREF, DATATAG, OMITTAG, RANK or SHORTTAG. * It was agreed that DTDs for use in data interchange should eschew the use of minimization features. It was pointed out however that RANK has other functions, while SHORTREF and DATATAG greatly aid the process of data capture, as do OMITTAG and SHORTREF which also can be of importance in data compression. DB opined that prohibiting all these features would need a "good sales job" for those who wanted the interchange format to be person-readable. He also suggested that the lengthy discussion of this point in TEI MLW1 was unnecessary, partly because minimisation features are specified in the SGML declaration which is independent of the DTD. It was suggested that general guidance on the use of minimization features in production systems might be useful. It was agreed that DTDs for datacapture must be derived from DTDs for transmission, with possible relaxation of the minimization constraints expressed in this recommendation. DB was requested to draft a document giving guidance on the intelligent use of minimization features during data capture. o * We recommend that attributes not be used in the declaration of DTDs or their instances * JPG pointed out that support for CONCUR implied that content (#PCDATA) associated with a tag visible in one view might be confused with content associated with another. SGML provided no way, other than attributes, of associating content with a view; only tags could be so associated. Alternative approaches (marked sections, for example) were even more cumbersome. Some of the arguments for and against the use of attributes, which had already been extensively presented before the meeting, were reiterated. LB felt that more justification for the removal of an existing and widely used feature was needed than that it arguably introduced unnecessary complexity. The committee voted on MSM's proposal that the recommendation be dropped from the document: this was agreed by a 6 to 1 majority. o * We recommend that the DTD definer avoid the use of inclusion and exclusion exceptions when defining DTDs * It was noted that model DTDs specified in Annex E of ISO 8879 actually contain inclusion and exclusion exceptions. The committee recognised the dangers of allowing thoughtless use of these features. Their prohibition however seemed to add to the psychological complexity of DTD definition. It was pointed out that while inclusion exceptions were a notational convenience, exclusion exceptions expressed part of the content model which might better be rewritten explicitly. JPG was requested to draft a paragraph outlining circumstances in which exceptions might be appropriately used. o * We recommend the use of the CONCUR feature * This recommendation was agreed.