Draft minutes of 2010-04 Council meeting - Revision history

Piotr Banski: Protected "Draft minutes of 2010-04 Council meeting": isn't this what you intended, Kevin? [edit=sysop:move=sysop]

2011-11-13T21:33:54Z

Protected "Draft minutes of 2010-04 Council meeting": isn't *this* what you intended, Kevin? [edit=sysop:move=sysop]

Kshawkin: Unprotected "Draft minutes of 2010-04 Council meeting": this content has been migrated to tei-c.org

2011-11-13T20:44:04Z

Unprotected "Draft minutes of 2010-04 Council meeting": this content has been migrated to tei-c.org

Kshawkin: added Category:Council

2011-04-15T18:18:19Z

added Category:Council

Kshawkin: link to archived version

2011-04-15T18:16:55Z

link to archived version

Kshawkin: /* hyphenation (and orthographical changes at line breaks) */ more from Lou

2010-06-06T16:34:07Z

‎hyphenation (and orthographical changes at line breaks): more from Lou

Kshawkin: /* hyphenation (and orthographical changes at line breaks) */ link to discussion of lb@type

2010-06-06T16:26:32Z

‎hyphenation (and orthographical changes at line breaks): link to discussion of lb@type

Kshawkin: /* hyphenation */ made corrections based on Lou's email to Council on 2010-05-23

2010-06-06T16:21:56Z

‎hyphenation: made corrections based on Lou's email to Council on 2010-05-23

Kshawkin: /* Second report (KH) */ clarified nesting of s

2010-05-28T04:02:20Z

‎Second report (KH): clarified nesting of <term>s

Brett: /* afternoon of 2010-04-30 */

2010-05-21T18:21:57Z

‎afternoon of 2010-04-30

Brett at 17:43, 21 May 2010

2010-05-21T17:43:10Z

← Older revision		Revision as of 18:18, 15 April 2011
Line 482:		Line 482:

	Action item: LB will close these.		Action item: LB will close these.
		+
		+	[[Category:Council]]

← Older revision		Revision as of 18:16, 15 April 2011
Line 1:		Line 1:
		+	'''Archival version is now at http://www.tei-c.org/Activities/Council/Meetings/tcm45.xml'''
		+
	The following are minutes of the 2010 Council meeting, held April 29-30 in Dublin.		The following are minutes of the 2010 Council meeting, held April 29-30 in Dublin.
−
−	~~A final version should be added to http://www.tei-c.org/Activities/Council/Meetings/index.xml along with the past meeting minutes.~~

	== morning of 2010-04-29 ==		== morning of 2010-04-29 ==

← Older revision		Revision as of 16:34, 6 June 2010
Line 258:		Line 258:

	Elena said this is exactly how the Austen project handled hyphenation.		Elena said this is exactly how the Austen project handled hyphenation.
		+
		+	[Alternatively, the hyphen could be left in the text and no rend attribute used.]

	Lou continued that this leaves the problem of handling hyphenation of words across line breaks in languages like Dutch and German, where letters within the word are sometimes duplicated before and after the hyphen. Juliana noted that Old Irish did something similar.		Lou continued that this leaves the problem of handling hyphenation of words across line breaks in languages like Dutch and German, where letters within the word are sometimes duplicated before and after the hyphen. Juliana noted that Old Irish did something similar.

@@ Line 255: / Line 255: @@
 In short, the Guidelines are currently not helpful in giving guidance on encoding hyphens that appear to be accidents of line breaks (where a hyphen would not appear in the word had there not been a line break).  It has been suggested to use the Unicode soft hyphen character for these cases, and Lou initially thought this would be appropriate; however, Deborah Anderson asked senior Unicode people about this and they told us that use of the soft hyphen for such cases is inappropriate.  (The soft hyphen is meant for cases where processing software might choose to break a word, not where it was previously broken.)
-If we instead used the lb element, how would you indicate whether the word was broken across lines?  You might use the type attribute to indicate whether a lexical unit has been broken by the hyphen, use whitespace before the element, or use the rend attrbute to describe the hyphenation.  Lou suggested using the type attribute to indicate whether the hyphen marks the boundary between lexical items and the rend attribute to describe how this boundary is indicated (using a hyphen, semicolon, etc.).  With this method, no hyphen is left as character data in the XML document.
+If we instead used the lb element, how would you indicate whether the word was broken across lines?  You might use the type attribute to indicate whether a lexical unit has been broken by the hyphen [as recommended in [http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-lb.html the element definition for the lb element]], use whitespace before the element, or use the rend attrbute to describe the hyphenation.  Lou suggested using the type attribute to indicate whether the hyphen marks the boundary between lexical items and the rend attribute to describe how this boundary is indicated (using a hyphen, semicolon, etc.).  With this method, no hyphen is left as character data in the XML document.
 Elena said this is exactly how the Austen project handled hyphenation.

@@ Line 245: / Line 245: @@
 It was also agreed that the discussion of cRef on the ticket should be "spun off" into a different ticket.
-=== hyphenation ===
+=== hyphenation (and orthographical changes at line breaks) ===
-Lou summarized the debate on how to handle encoding of hyphenation.
+Lou summarized the debate on appropriate use of the soft hyphen character, which is closely related to the question of how to encode hyphenation when also encoding line breaks.
-If you are transcribing early printed books with hyphens at the end of lines, there are a number of ways to do it.  If your goal is to transcribe text, including hyphens, faithfully or to encode the text in a way that will allow you to process lexical items (generally speaking, words) without marking up these words with w elements, you will need to represent hyphenation in the source document.
+As he explained, if you are transcribing early printed books with hyphens at the end of lines, there are a number of ways to do it.  If your goal is to transcribe text, including hyphens, faithfully or to encode the text in a way that will allow you to process lexical items (generally speaking, words) without marking up these words with w elements, you will need to represent hyphenation in the source document.
-If your encoding will mark line breaks (using lb), this complicates the method for encoding hyphenation and requires any tokenization software to be capable to ignoring elements that can appear within words (like lb). Alternatively, a derived text with lb and other intraword elements removed could be produced for the concordance software from the master encoded text.
+If your encoding will mark line breaks (using lb), this complicates the method for encoding hyphenation and requires any tokenization software to be capable of ignoring elements that can appear within words (like lb). Alternatively, a derived text with lb and other intraword elements removed could be produced for the concordance software from the master encoded text.
 In short, the Guidelines are currently not helpful in giving guidance on encoding hyphens that appear to be accidents of line breaks (where a hyphen would not appear in the word had there not been a line break).  It has been suggested to use the Unicode soft hyphen character for these cases, and Lou initially thought this would be appropriate; however, Deborah Anderson asked senior Unicode people about this and they told us that use of the soft hyphen for such cases is inappropriate.  (The soft hyphen is meant for cases where processing software might choose to break a word, not where it was previously broken.)
@@ Line 260: / Line 260: @@
 Lou continued that this leaves the problem of handling hyphenation of words across line breaks in languages like Dutch and German, where letters within the word are sometimes duplicated before and after the hyphen.  Juliana noted that Old Irish did something similar.
 Lou said that it's not clear where to put the lb element and said it would seem you would need to repeat it.  Brett suggested a standoff choice element.  Elena said that the Austen project used xml:id and corresp.  Matthew said that [some project he was involved in] used sameAs with xml:id.

← Older revision	Revision as of 21:33, 13 November 2011
(No difference)

← Older revision	Revision as of 20:44, 13 November 2011
(No difference)

@@ Line 367: / Line 367: @@
 ===Second report (KH)===
 *2900430
-**Decided they prefer having one or more <term> elements w/in <keywords>. Should you believe that there is a nested list, such is already allowed.
+**Decided they prefer having one or more <term> elements w/in <keywords>. Should you believe that there are nested terms in a compound subject term like "History -- Russia", such is already allowed by nesting term elements.
 **Examples in guidelines will need to be changed.
@@ Line 427: / Line 427: @@
 *If the semantics of the @ref are implied, you just call it @ref; otherwise, (e.g., scribeRef, @lemmaRef).
 *We recommend anchoring URN mechanism when possible, but unregistered URNs are allowed (and allowed by W3C as well).
 *We will change the guidelines.
 ===Wrap-up===

← Older revision		Revision as of 18:21, 21 May 2010
Line 311:		Line 311:

	== afternoon of 2010-04-30 ==		== afternoon of 2010-04-30 ==
		+
		+	Reconvened at app. 1:15
		+
		+	On LR's suggestion, the council reviewed the amber bug reports and summarized each.
		+
		+	*2964254
		+	**KH summarized, saying that according to element definition of <keywords>, "term" is misused. Short discussion regarding the location of the problem in the guidelines followed.
		+
		+	*2963461
		+	**SR: This is an implementation problem.
		+
		+	*2955059
		+	**Discussion of history of use. Conclusion is for LB to clear up discussion of use cases in the guidelines.
		+
		+	*2945206
		+	**Problem with Vesta
		+
		+	*2938882
		+	**Problem with Vesta
		+
		+	*2938735
		+	**LB: For historical reasons, @hand of att.transcriptional is declared as data.pointer, but the @new <handShift> is declared as data.code
		+	**It was decided that this would be treated further in the break-out sessions
		+
		+	*2932853
		+	**Agreed to make consistent (see LB's comment at SF)
		+
		+	*2915506
		+	**LB summarized J Walsh's use case, which involved use of <bibl> in tabular data. LB opined that this was tag abuse. Council members were unable to imagine alternative scenarios in which label as described might need <bibl>. SR floated alternative suggestion of including <bibl> in macro.phraseSec. No need for changes of any kind at this time.
		+
		+	*2900430
		+	**EP and DO favor first proposal. LB noted that redefining will break backward compatibility. EP noted that the second proposal (<scriptNotes> with <scriptNote> children) wouldn't break backward compatibility. LR proposed that for now we agree that a mechanism is needed but that we defer a decision about the specifics until the key/ref decisions have been made. Agreed.
		+
		+	*2714682
		+	**KH: Compassed by the proposals and actions put forth yesterday.
		+
		+
		+	---Breakout---
		+
		+	Reconvened at 2:05
		+
		+	===First report (EP)===
		+	*Propose using @hand and deprecate @new on <handShift>
		+	*Propose rejecting the request to make @hand global attribute. Reason: doesn't solve the overlapping problem.
		+	*Propose revising the guidelines to recommend using <handShift> at the beginning if you will use it later.
		+	*Propose revising the guidelines to recommend similar use of all milestone elements.
		+
		+	**LB brought up the use-case of the First Folio, but he agreed after discussion that it doesn't present a problem.
		+
		+	*Propose a new element for quire-breaks.
		+	**[some debate]
		+	**LR Noted that this has already been added as a SF ticket
		+	**EP also noted that the issue of uncertainty whether a hand is A or B was not addressed.
		+
		+	===Second report (KH)===
		+	*2900430
		+	**Decided they prefer having one or more <term> elements w/in <keywords>. Should you believe that there is a nested list, such is already allowed.
		+	**Examples in guidelines will need to be changed.
		+
		+
		+	LR: We have thus dealt with all of the amber bugs & feature requests.
		+
		+	2:20
		+
		+	LR: Would like to treat @key / @ref and deprecation mechanisms.
		+
		+	--small break--
		+
		+	LR: We need a way to have a "soft" deprecation, a way of explaining to the community that they shouldn't use a certain practice that was formerly allowed/recommended. We don't want to enforce a strict mechanism (one that breaks compatibility). Proposes that in future (minutes, etc.) we use "deprecation" in this way.
		+
		+	[discussion of where the deprecation takes place. DO, e.g., floats idea of an appendix in which all things marked as deprecated are gathered.]
		+
		+	General agreement that we need a formal way of marking the deprecation (e.g., <note type="deprecated">).
		+
		+	DO: proposes a small working group, but this proposal was not met w/ enthusiasm.
		+
		+	Discussion of creating some way to flag not only deprecated practice but also recommended practice. Reference to ISO and W3C uses of "required" etc.
		+
		+	LB: We had two ways of noting the canonical home of an item: @key or @ref. John Walsh wanted a "magic token" pointer for @facsKey. Occurred to folks that URIs need not be URL. Proposal is to deprecate @key and make clear that @ref can be used.
		+
		+	SB: If there are places where only @key is available, do we add @ref (moduleRef)? Do we recommend a way to compose the "magic token"?
		+
		+	LB: There's a syntax for URN's, so that's one option.
		+
		+	LR: What are the opinions of folks outside the TEI?
		+
		+	LB: Some geeks have said it's OK. Objections incl. that we should use registered URNs.
		+
		+	Discussion about
		+
		+	- persistence assumption in URN scheme.
		+
		+	LB: Proposal is to continue to allow @ref to use A URI, which can be a URN, but it doesn't have to be.
		+
		+	JC: Do people think that the TEI should be registering themselves as a proper URN?
		+
		+	[seems to be affirmation]
		+
		+	SR: Original problem that John Walsh raises can be solved other ways, too. E.g., he can use a local web service that resolves an arbitrary identifier.
		+
		+	KH: Or we could also recommend that users register a URN.
		+
		+	[people seem to like this option]
		+
		+	KH: Are we OK withLou's recommendation that we prefer @ref?
		+
		+	[unanymous agreement]
		+
		+	LR: Issue of synonyms (e.g., @lemmaRef vs. other elements that just use @ref).
		+
		+	KH: We should probably also change examples in the guidelines that use (only) @key (to add also examples w/ @ref).
		+
		+	LR: Summary: We have a set of guidelines for dealing w/ @key at large. This will allow us to deal with several outstanding issues:
		+
		+	*If the semantics of the @ref are implied, you just call it @ref; otherwise, (e.g., scribeRef, @lemmaRef).
		+	*We recommend anchoring URN mechanism when possible, but unregistered URNs are allowed (and allowed by W3C as well).
		+	*We will change the guidelines.
		+
		+	===Wrap-up===
		+
		+	SR: Do board members have anything they want to the Council to consider?
		+
		+	SS: Encouraging participation of Council members in the SIGs.
		+
		+	DO: Proposes assigning new Council members to a SIG and expect a report.
		+
		+	[discussion of the problem that comes from people rotating off]
		+
		+	DO: will put in a feature request to have a more formal system of rep. of Council members on the SIGs:
		+
		+	*correspondence
		+	*education
		+	*libraries
		+	*manuscripts
		+	*music
		+	*ontologies
		+	*scholarly publishing
		+	*text and graphics
		+	*tools
		+
		+	JN: the journal's publication of the "getting started" document.
		+
		+	LR: It was a great idea, but probably too ambitious to take on as a Council project. But the existing TOC and what's already there are good.
		+
		+	JN: What about authorship attribution of the existing material?
		+
		+	LB: No sense that there is a strong feeling on the Council that they want to retain ownership.
		+
		+	JC: Does the council want to have a regular place in TEI-EJ to say, "This is what's been happening"?
		+
		+	LR & JN: Probably not a good idea.
		+
		+	[discussion of the maintenance of the TEI website (stable URIs to bits of the guidelines; new newsServer; status of material in the vault)]
		+
		+	Action item: SR will contact David Sewell about putting search box in guidelines on the TEI site
		+
		+	LR: We've made good progess. The publishing issue: Our wrap-up after the mtg. didn't completely satisfy him. He will need to talk more with Ken. Hyphenation was a productive discussion.
		+
		+	EP: Having the manuscripts proposals accepted in principle is satisfying. Thinks it is essential that the SIG has space to put things (put up different versions of the documents, acknowledge people who have contributed, etc.).
		+
		+	DO: Action has already begun to have this happen.
		+
		+	LR: Plan is to use the "feature request" system, right?
		+
		+	ER: Yes, will do this with Lou. There are certain existing feature requests that should be closed because we've decided on other protocols for handling them.
		+
		+	Action item: LB will close these.

@@ Line 37: / Line 37: @@
 *2971316 - Add @svg:points to att.coordinated
 **no objections; much rejoicing.
 *2969870 - &lt;surrogates&gt; for digital &amp; its examples
 **general agreement.
 *2949985 - &lt;idno&gt; in more than just bibliographic elements
 **Following a brief discussion in which LR et al. parsed the similarity of &lt;idno&gt;, &lt;num&gt;, and &lt;term&gt;; in which LB opined that a phrase-level &lt;idno&gt; would not be a good idea; and in which the classes &lt;idno&gt; might be added to were discussed, it was agreed that &lt;idno&gt; should be added to model.nameLike.
 *2728061 - Add @target to relatedItem
@@ Line 51: / Line 54: @@
 *2946056 - order of children of profileDesc
 **After some debate such things as whether &lt;creation&gt; should be repeatable, Council agreed to add it to model.profileDescPart, perhaps also adding a Schematron rule to prevent its being repeated.
 *2863331 - 'Used by' section empty in model.physDescPart
@@ Line 59: / Line 63: @@
 *2976608 - Add &lt;ref&gt; as a child of &lt;analytic&gt;, &lt;monogr&gt; and &lt;series&gt;
 **Numerous example use cases were put forth, and the Council agreed to the change as proposed.
 *2973254 - Allow @target (or &lt;ptr&gt;) on &lt;divGen&gt;
 **DO et al. argued that this request would amount to a hack for replicating the functionality of XInclude. JC pointed out that the TEI website uses OpenCMS, which doesn't allow Xinclude. Council members generally agreed that, while hacks could be countenanced in such situations, they shouldn't be written into the spec.
 *2940838 - CALS for TEI
 **This request grows out of a discussion between LR and SR regarding Sebastian's use of CALS in ISO. LR clarified that the request isn't that we take up responsibility for CALS itself. In response to KH's question whether the proposal is that we "make CALS available" just via a reference in the prose of the guidelines, LR responded that he would like to see, at minimum, something in Roma to allow CALS. SR opined that perhaps no action by the Council was needed. After further discussion of whether we should support CALS through the TEI Sourceforge site. It was decided that this request should be added to the roster for further discussion later in the meeting.
 *2925145 - Generic dating class
 **Following a summary of the request by LB, JC noted that it's not the TEI that's saying you have to use the Gregorian calendar, but ISO. DO pointed out that we've done this sort of things for &lt;dimension&gt; (@unit). Observing that the request obviously warrants debate, LR moved the request to the roster for later discussion.
 *2919640 - global @facsKey
 **It was agreed to close this ticket, as @facs currently permits any of the 3 options Sebastian outlined in his comment. The Council favored Sebastian's choice "a" and agreed that the guidelines should be amended to include recommendations and/or examples regarding how to implement this suggestion.
-−
 *2909766 - make &lt;del&gt; and &lt;add&gt; (etc) dateable
 **On the advice of SR, the Council decided to defer further discussion of this request until they had an opportunity to consider the recommendations of the working group on genetic editions.
 *2890254 - ability to define new element with same name as an existing
@@ Line 125: / Line 135: @@
 *2298442 2298442 - ODD should customize ODD
 **It was decided that further discussion of this request should be deferred until after discussion of ODD+.
 == afternoon of 2010-04-29 ==