Paris 2011-11 minutes - Revision history

Kshawkin: Protected "Paris 2011-11 minutes": now on www.tei-c.org ([edit=sysop] (indefinite) [move=sysop] (indefinite))

2011-11-25T15:18:08Z

Protected "Paris 2011-11 minutes": now on www.tei-c.org ([edit=sysop] (indefinite) [move=sysop] (indefinite))

Kshawkin: link to official version

2011-11-25T15:17:11Z

link to official version

Kshawkin: added wiki category

2011-11-13T20:43:16Z

added wiki category

Piotr Banski: /* GENETIC TRANSCRIPTION: */

2011-11-13T16:22:07Z

‎GENETIC TRANSCRIPTION:

Mholmes: /* GENETIC TRANSCRIPTION: */

2011-11-12T07:09:44Z

‎GENETIC TRANSCRIPTION:

Mholmes: /* GENETIC TRANSCRIPTION: */

2011-11-12T06:45:30Z

‎GENETIC TRANSCRIPTION:

Piotr Banski: cosmetics

2011-11-11T21:54:39Z

cosmetics

Show changes

Piotr Banski: /* SIG report from the Linguistics SIG ( ''PB'' ) */ (the report was on a single item, more of a FYI)

2011-11-11T21:46:08Z

‎SIG report from the Linguistics SIG ( ''PB'' ): (the report was on a single item, more of a FYI)

Piotr Banski: /* Discussion topics */

2011-11-11T21:41:22Z

‎Discussion topics

Piotr Banski: /* Other Issues */

2011-11-11T21:32:54Z

‎Other Issues

← Older revision		Revision as of 15:17, 25 November 2011
Line 1:		Line 1:
		+	'''Official version at http://www.tei-c.org/Activities/Council/Meetings/tcm48.xml'''
		+
	== November 7 2011 ==		== November 7 2011 ==

← Older revision		Revision as of 20:43, 13 November 2011
Line 294:		Line 294:

	Investigate methods of allowing element and attribute name aliasing, so that we could rename elements without breaking backward compatibility.		Investigate methods of allowing element and attribute name aliasing, so that we could rename elements without breaking backward compatibility.
		+
		+	[[Category:Council]]

@@ Line 108: / Line 108: @@
 EP: There are some major problems with the chapter as it stands:
-#The opening with two facing pages, with a patch crossing the two pages, or where the author has considered the opening as a single surface (e.g. Proust's working texts). EP proposed to the Goethe working group that a single <surface> be used in this case; this means that <surface> is being used as a psychological. The working group responded positively to this, and Council thinks it's uncontroversial. EP has examples, and will provide one from Proust, because the chapter should have one. BB: the chapter currently reads as though a <surface> is a physical object, or exists prior to interpretation, but we need to modify that description so that it allows for, or even specifies, the fact that a <surface> is a psychological construct of the encoder, presumably based on the assumed perception of the original author who chose to use it that way. JC: Why shouldn't this situation be handled by nesting <surface>? EP: In this case, you could represent the page <surface>s side-by-side, rather than nesting them. There is no need for nesting.
+#The opening with two facing pages, with a patch crossing the two pages, or where the author has considered the opening as a single surface (e.g. Proust's working texts). EP proposed to the Goethe working group that a single <surface> be used in this case; this means that <surface> is being used as a psychological construct. The working group responded positively to this, and Council thinks it's uncontroversial. EP has examples, and will provide one from Proust, because the chapter should have one. BB: the chapter currently reads as though a <surface> is a physical object, or exists prior to interpretation, but we need to modify that description so that it allows for, or even specifies, the fact that a <surface> is a psychological construct of the encoder, presumably based on the assumed perception of the original author who chose to use it that way. JC: Why shouldn't this situation be handled by nesting <surface>? EP: In this case, you could represent the page <surface>s side-by-side, rather than nesting them. There is no need for nesting.
 #A mini-<surface> within an existing <surface> is represented as a <patch>. If the patch is written on both sides, then it's @flippable, but how do we distinguish that from two separate patches? JC, LR: We need nested surfaces to handle this. LB: <patch> is just a special kind of <surface>. Should we collapse it into the definition of <surface>? LB suggests we kill <patch>, and we introduce something called <surfaceGrp>, of which the prototypical case is a "leaf"; another example is a pile of post-it notes on top of each other. A <surfaceGrp> is not a matter of interpretation; it's a physical object which includes multiple <surface>s. EP objects to the idea of physical objects, because all determination of <surface> is by the encoder; we can't really express physical reality. MH, JC: A <surfaceGrp> could not have a single coordinate space because it is not a single two-dimensional space; a <surfaceGrp> can have a location within the coordinate space of its parent <surface>, and its child <surface>s have their own coordinate spaces. The group consensus now is that what we were thinking of as a patch could be represented either as a nested <surface> (in the case of a single pasted object with only one significant face) or a <surfaceGrp> (in the case of a flippable two-sided object, or a multi-page booklet pasted onto the parent surface). Both <surface> and <surfaceGrp> therefore need to be able to express their dimensions within the coordinate space of their parent <surface>; in the case of a nested <surface>, it may also define its own coordinate space which act as the context for <zone> elements defined within it. <surfaceGrp> may be a child of <facsimile> or <sourceDoc>.
 #The leaf concept has been largely covered with <surfaceGrp>, but there's the issue of transparency; a writer may interact with something visible from the other side of a leaf, by e.g. doodling around it. MH: this might be handled through an attribute on <zone>, such as "bleedThrough".

@@ Line 109: / Line 109: @@
 EP: There are some major problems with the chapter as it stands:
 #The opening with two facing pages, with a patch crossing the two pages, or where the author has considered the opening as a single surface (e.g. Proust's working texts). EP proposed to the Goethe working group that a single <surface> be used in this case; this means that <surface> is being used as a psychological. The working group responded positively to this, and Council thinks it's uncontroversial. EP has examples, and will provide one from Proust, because the chapter should have one. BB: the chapter currently reads as though a <surface> is a physical object, or exists prior to interpretation, but we need to modify that description so that it allows for, or even specifies, the fact that a <surface> is a psychological construct of the encoder, presumably based on the assumed perception of the original author who chose to use it that way. JC: Why shouldn't this situation be handled by nesting <surface>? EP: In this case, you could represent the page <surface>s side-by-side, rather than nesting them. There is no need for nesting.
-#A mini-<surface> within an existing <surface> is represented as a <patch>. If the patch is written on both sides, then it's @flippable, but how do we distinguish that from two separate patches? JC, LR: We need nested surfaces to handle this. LB: <patch> is just a special kind of <surface>. Should we collapse it into the definition of <surface>? LB suggests we kill <patch>, and we introduce something called <surfaceGrp>, of which the prototypical case is a "leaf"; another example is a pile of post-it notes on top of each other. A <surfaceGrp> is not a matter of interpretation; it's a physical object which includes multiple <surface>s. EP objects to the idea of physical objects, because all determination of <surface> is by the encoder; we can't really express physical reality. MH, JC: A <surfaceGrp> could not have a single coordinate space because it is not a single two-dimensional space; a <surfaceGrp> can have a location within the coordinate space of its parent <surface>, and its child <surface>s have their own coordinate spaces. LB: Take the single canonical example of a leaf: the size of a leaf on one side is the same as its side on the other. Therefore we should allow a default coordinate system on <surfaceGrp>. The group consensus now is that what we were thinking of as a patch could be represented either as a nested <surface> (in the case of a single pasted object with only one significant face) or a <surfaceGrp> (in the case of a flippable two-sided object, or a multi-page booklet pasted onto the parent surface). Both <surface> and <surfaceGrp> therefore need to be able to express their dimensions within the coordinate space of their parent <surface>; in the case of a nested <surface>, it may also define its own coordinate space which act as the context for <zone> elements defined within it. <surfaceGrp> may be a child of <facsimile> or <sourceDoc>.
+#A mini-<surface> within an existing <surface> is represented as a <patch>. If the patch is written on both sides, then it's @flippable, but how do we distinguish that from two separate patches? JC, LR: We need nested surfaces to handle this. LB: <patch> is just a special kind of <surface>. Should we collapse it into the definition of <surface>? LB suggests we kill <patch>, and we introduce something called <surfaceGrp>, of which the prototypical case is a "leaf"; another example is a pile of post-it notes on top of each other. A <surfaceGrp> is not a matter of interpretation; it's a physical object which includes multiple <surface>s. EP objects to the idea of physical objects, because all determination of <surface> is by the encoder; we can't really express physical reality. MH, JC: A <surfaceGrp> could not have a single coordinate space because it is not a single two-dimensional space; a <surfaceGrp> can have a location within the coordinate space of its parent <surface>, and its child <surface>s have their own coordinate spaces. The group consensus now is that what we were thinking of as a patch could be represented either as a nested <surface> (in the case of a single pasted object with only one significant face) or a <surfaceGrp> (in the case of a flippable two-sided object, or a multi-page booklet pasted onto the parent surface). Both <surface> and <surfaceGrp> therefore need to be able to express their dimensions within the coordinate space of their parent <surface>; in the case of a nested <surface>, it may also define its own coordinate space which act as the context for <zone> elements defined within it. <surfaceGrp> may be a child of <facsimile> or <sourceDoc>.
 #The leaf concept has been largely covered with <surfaceGrp>, but there's the issue of transparency; a writer may interact with something visible from the other side of a leaf, by e.g. doodling around it. MH: this might be handled through an attribute on <zone>, such as "bleedThrough".
 #EP: BB raised the issue of @alt on the list; exactly what did he mean? BB: I'll have to go back and look at that again.

@@ Line 109: / Line 109: @@
 EP: There are some major problems with the chapter as it stands:
 #The opening with two facing pages, with a patch crossing the two pages, or where the author has considered the opening as a single surface (e.g. Proust's working texts). EP proposed to the Goethe working group that a single <surface> be used in this case; this means that <surface> is being used as a psychological. The working group responded positively to this, and Council thinks it's uncontroversial. EP has examples, and will provide one from Proust, because the chapter should have one. BB: the chapter currently reads as though a <surface> is a physical object, or exists prior to interpretation, but we need to modify that description so that it allows for, or even specifies, the fact that a <surface> is a psychological construct of the encoder, presumably based on the assumed perception of the original author who chose to use it that way. JC: Why shouldn't this situation be handled by nesting <surface>? EP: In this case, you could represent the page <surface>s side-by-side, rather than nesting them. There is no need for nesting.
-#A mini-<surface> within an existing <surface> is represented as a <patch>. If the patch is written on both sides, then it's @flippable, but how do we distinguish that from two separate patches? JC, LR: We need nested surfaces to handle this. LB: <patch> is just a special kind of <surface>. Should we collapse it into the definition of <surface>? LB suggests we kill <patch>, and we introduce something called <surfaceGrp>, of which the prototypical case is a "leaf"; another example is a pile of post-it notes on top of each other. A <surfaceGrp> is not a matter of interpretation; it's a physical object which includes multiple <surface>s. EP objects to the idea of physical objects, because all determination of <surface> is by the encoder; we can't really express physical reality. MH, JC: A <surfaceGrp> could not have a single coordinate space because it is not a single two-dimensional space; a <surfaceGrp> can have a location within the coordinate space of its parent <surface>, and its child <surface>s have their own coordinate spaces. LB: Take the single canonical example of a leaf: the size of a leaf on one side is the same as its side on the other. Therefore we should allow a default coordinate system on <surfaceGrp>. The group consensus now is that <surfaceGrp> should replace <patch>; it covers both the use case of <patch> and other cases such as four-sided monuments or leaves; <surfaceGrp> is a child of <surface>, and <surface> is its child; <surfaceGrp> needs to be able to express its location and size within the coordinate space of its parent <surface>, assuming it has a parent <surface>. <surfaceGrp> may be a child of <facsimile> or <sourceDoc>.
+#A mini-<surface> within an existing <surface> is represented as a <patch>. If the patch is written on both sides, then it's @flippable, but how do we distinguish that from two separate patches? JC, LR: We need nested surfaces to handle this. LB: <patch> is just a special kind of <surface>. Should we collapse it into the definition of <surface>? LB suggests we kill <patch>, and we introduce something called <surfaceGrp>, of which the prototypical case is a "leaf"; another example is a pile of post-it notes on top of each other. A <surfaceGrp> is not a matter of interpretation; it's a physical object which includes multiple <surface>s. EP objects to the idea of physical objects, because all determination of <surface> is by the encoder; we can't really express physical reality. MH, JC: A <surfaceGrp> could not have a single coordinate space because it is not a single two-dimensional space; a <surfaceGrp> can have a location within the coordinate space of its parent <surface>, and its child <surface>s have their own coordinate spaces. LB: Take the single canonical example of a leaf: the size of a leaf on one side is the same as its side on the other. Therefore we should allow a default coordinate system on <surfaceGrp>. The group consensus now is that what we were thinking of as a patch could be represented either as a nested <surface> (in the case of a single pasted object with only one significant face) or a <surfaceGrp> (in the case of a flippable two-sided object, or a multi-page booklet pasted onto the parent surface). Both <surface> and <surfaceGrp> therefore need to be able to express their dimensions within the coordinate space of their parent <surface>; in the case of a nested <surface>, it may also define its own coordinate space which act as the context for <zone> elements defined within it. <surfaceGrp> may be a child of <facsimile> or <sourceDoc>.
-#The leaf concept has been largely covered with <surfaceGrp>, but there's the issue of transparency; a writer may interact with something visible from the other side of a leaf, by e.g. doodling around it. MH: this might bve handled through an attribute on <zone>, such as "bleedThrough".
+#The leaf concept has been largely covered with <surfaceGrp>, but there's the issue of transparency; a writer may interact with something visible from the other side of a leaf, by e.g. doodling around it. MH: this might be handled through an attribute on <zone>, such as "bleedThrough".
 #EP: BB raised the issue of @alt on the list; exactly what did he mean? BB: I'll have to go back and look at that again.
 '''SUMMARY''': LB will rework the draft, and do it as fast as possible; he'll then ask all Council members to read the whole thing again. We should allow three working days, including if possible a weekend, to do the appropriate level of proofing.
 ====AMBER TICKETS:====

← Older revision	Revision as of 15:18, 25 November 2011
(No difference)

@@ Line 281: / Line 281: @@
 ====SIG report from the Linguistics SIG ( ''PB'' )====
-''PB'' has sent a SIG report to the Council, which we will read and discuss on the mailing list. Action for ''JC'' : Before Council meetings, email the SIG lists to ask for reports or issues to discuss.
+''PB'' has sent to the Council a report on the [https://www.zotero.org/groups/tei-lingsig/items/ TEI/linguistic bibliography list], created and maintained in the context of LingSIG. Action for ''JC'' : Before Council meetings, email the SIG lists to ask for reports or issues to discuss.
 ====Priorities for the Next Year====

@@ Line 234: / Line 234: @@
 # '''''P4 survey report''''' : JC did a survey of usage of P4, in advance of its scheduled end-of-life: [http://blogs.oucs.ac.uk/jamesc/2011/10/27/tei_p4_support/ http://blogs.oucs.ac.uk/jamesc/2011/10/27/tei_p4_support/] . ''JC'' : this basically gives us encouragement to start moving P4 to the Vault over the next year.
 # '''''...Grp vs. list...''''' ( ''BB'' , ''LB'' , ''PB'' ): The current situation is horrible:
+#:<code>
                  lou@THIMK:~/Public/TEI-SF/P5/Source/Specs$ ls -1 list*.xml
                  listBibl.xml
@@ Line 273: / Line 272: @@
                  castGroup.xml</code>
-''EP'' : We could try to use ''<equiv>'' to make element aliasing work, and then rationalize the names; we could push this problem forward to P6, and develop an explicit strategy for naming these things; or we could throw up our hands and do nothing. ''PB'' : We should fix ''<transposeGrp>'' while we can. We should develop a clear set of naming principles for these things. ''LB'' : There is a general section in the Guidelines on naming of elements. A description should go there. ''LR'' : It should go in tagDocs because people use that when writing ODDs. ''LB'' : All but a handful of the ''<*Grp>'' elements are syntactically correcxt as groups; the exceptions are ''<transposeGrp>'' , which we've agreed to change, ''<forestGrp>'' , and ''<relationGrp>'' . ''LB'' will raise a ticket for this.
+::''EP'' : We could try to use ''<equiv>'' to make element aliasing work, and then rationalize the names; we could push this problem forward to P6, and develop an explicit strategy for naming these things; or we could throw up our hands and do nothing. ''PB'' : We should fix ''<transposeGrp>'' while we can. We should develop a clear set of naming principles for these things. ''LB'' : There is a general section in the Guidelines on naming of elements. A description should go there. ''LR'' : It should go in tagDocs because people use that when writing ODDs. ''LB'' : All but a handful of the ''<*Grp>'' elements are syntactically correct as groups; the exceptions are ''<transposeGrp>'' , which we've agreed to change, ''<forestGrp>'' , and ''<relationGrp>'' . ''LB'' will raise a ticket for this.
 # '''''Magic tokens''''' ( ''JC'' , ''KH'' , ''LR'' ): The consensus is that we could integrate within ''@ref'' all the usages currently covered by ''@key'' , so the vision for the future is that we don't need ''@key'' . However, ''@key'' is widely used right now, so we should not remove it or deprecate it. We should modify the Guidelines to make the point that people should switch to ''@ref'' wherever ''@key'' is mentioned. ''KH'' will create a ticket and start implementing it.
 # '''''Translations''''' ( ''MH'' , ''EP'' ): First, how should we realign the translations from 2007? Second, how do we put a system in place to ensure that translations don't get too far behind? Before we can act, though, we need to know whether the TEI prioritizes it or not, and is willing to put some money into it. To do that, we really need to do a survey of the community; such a survey would have to be multilingual, and we would need to make sure we can reach non-English-speaking users, so we'll have to issue a multilingual call, and ask TEI-L users to circulate it among their communities. ''PB'' : Adding requirements for translation of every change can actually make the maintainers of a project reluctant to make needed changes. We could also go for a wiktionary approach for element definitions, but that would be another environment to maintain. ''LR'' : First action is to issue a multilingual survey; second action is to implement models for translation environments and tools; thirdly, we need to find a way to officially validate or certify translations. We should report our intentions to the Board through ''EP'' , and we will raise a ticket that ensures we return to the issue at the next meeting.

@@ Line 226: / Line 226: @@
 =====Other Issues=====
-# ''EP'' asked that we create a link on the TEI site to a filtered list of SF tickets includinmg only the deprecation tickets, so people can easily see what is currently deprecated. ''MH'' suggested there be two lists, one showing open deprecation tickets and one showing closed (because enacted) deprecation tickets. ''LB'' opened a ticket for this, and assigned it to ''JC'' .
+# ''EP'' asked that we create a link on the TEI site to a filtered list of SF tickets including only the deprecation tickets, so people can easily see what is currently deprecated. ''MH'' suggested there be two lists, one showing open deprecation tickets and one showing closed (because enacted) deprecation tickets. ''LB'' opened a ticket for this, and assigned it to ''JC'' .
 ====Afternoon====