<font face="Default Sans Serif,Verdana,Arial,Helvetica,sans-serif" size="2"> &gt; It should be noted that, as elsewhere in these Guidelines, this chapter<br>&gt; places more emphasis on the problems of representing the textual components<br>&gt; of a document than on those relating to the description of the document's<br>&gt; physical characteristics such as the carrier medium or physical construction.<br>&gt; These aspects, of particular importance in codicology and the bibliographic<br>&gt; study of incunables, are touched on in the chapter on Manuscript Description<br>&gt; (10 Manuscript Description) and also form the subject of ongoing work in the<br>&gt; TEI Physical Bibliography workgroup.<br><br>Is the binary "textual components" vs. "physical characteristics" still<br>satisfactory? I wonder whether the diplomatic transcription discussion puts<br>the lie to this statement, now, or at least makes it need more nuance.<br><br>"ongonig work in the TEI Physical Bibliography workgroup" Again wondering<br>whether this is still the right way to put this.<br><br>&gt; These Guidelines are mostly concerned with the preparation of digital texts,<br>&gt; in which a pre-existing text is transcribed or otherwise converted into<br>&gt; character form, and marked up in XML.<br><br>Tiny point, but the comma adfter "texts" would seem to indicate a<br>non-restrictive clause, but it turns out to be a *restrictive* clause, so the<br>comma should be deleted. (I.e., the bit following "digital texts" doesn't<br>define that term but specifies which ones are meant.<br><br>&gt; att.global.change supplies the change attribute, allowing its member elements<br>&gt; to specify one or more states or revision campaigns with which they are<br>&gt; associated.<br><br>still doesn't seem to allow for the possibility of grouping changes whose<br>association is not defined by temporality (e.g., those changes that are<br>marked in red because they have to do with correction vs. those marked in<br>black because they have to do with revision).<br><br>&gt; If a digital text contains one image per page or column (or similar unit),<br>&gt; and no more complex mapping between text and image is envisaged, then the<br>&gt; facs attribute may be used to point directly to a graphic resource:<br><br>Just a bad sentence (flabby to the point of saying nothing at the end, I'd argue),<br>but I'm OK with letting it slide.<br><br>&gt; By convention, this encoding indicates that the image indicated by facs<br>&gt; attribute<br><br>---!!!!! As I commented before, I think there's a "the" missing before "facs"<br><br>&gt; And it makes the management of the information about the images more<br>&gt; difficult by scattering references to them through the file.<br><br>Is this true? (Honest question. I just don't know what sort of "management<br>of the information" is being posited.)<br><br>&gt; individuals appearing in a group portraits<br><br>---!!!!! I pointed this out long ago and thought it had been fixed.<br><br>&gt; surface defines a written surface in terms of a rectangular coordinate space,<br>&gt; optionally grouping one or more graphic representations of that space, and<br>&gt; rectangular zones of interest within it.<br><br>I *think* that "rectangular" here is now passe, since zones need not be<br>rectangular (?)<br><br>&gt; a legal TEI document may thus comprise any of the following:-<br><br>seems to be a typo (extra "-" at the end)<br><br>&gt; A surface might be a sheet of paper or parchment<br><br>Not the sheet but one side of it, no? (unless it's a mobius strip) Maybe:<br>"A surface might be one side of a sheet of paper or parchment"<br><br>---!!!!! As I said before: "Also, I'm not sure why the definition of<br>att.coordinated is repeated in such a short space. I would think that the two<br>could be combined and all of the attributes listed at once and then discussed<br>one by one, in the ways that I believe the discussions of other attribute<br>classes elsewhere are organized."<br><br>Also: for the &lt;des&gt; of the class, could we change it to something like:<br>"provides attributes which can be used to position an element within a two<br>dimensional coordinate system."<br><br>&gt; in neither case is any specific mapping to the physical dimensions of the<br>&gt; object represented implied.<br><br>Awkward. Perhaps: "in neither case is any specific mapping to the dimensions of<br>the physical object implied."<br><br>OR (if need be): "Neither practice implies any specific mapping to the<br>physical dimensions of the object represented."<br><br>&gt; 34<br>&gt; <br>&gt; A zone may be used to define any region of interest, such as a detail or<br>&gt; illustration,<br><br>The footnote indicator "34" seems misplaced?<br><br>&gt; each of which specifies a point on the line surrounding the zone.<br><br>Not my area of specialty, so I'm happy to be wrong, but I would have<br>thought a rectangle has more than one line?<br><br>&gt; Note that this mechanism does not provide any way of addressing a<br>&gt; non-rectangular area, nor of coping with distortions introduced by<br>&gt; perspective or parallax; if this is needed, the more powerful mechanisms<br>&gt; provided by the Scalable Vector Graphics (SVG) language 35 should be used to<br>&gt; define an overlay, as further discussed in 16.4.3 A Three-way Alignment.<br><br>This is confusing to me for several reasons. 1) It seems that the mechanism<br>just described has very explicitly explained how to address non-rectangular<br>areas; 2) What do distortions have to do with anything, since the reference<br>is to the digital image rather than to the physical object?<br><br>&gt; The coordinates of the surface (that is, the area of the image which<br>&gt; represents the written two page spread)<br><br>---!!!!!! This is more of the problem that I was trying to call attention to<br>when I wrote about what seemed to me a confounding of physical surfaces and<br>surfaces as defined by the encoder. There *is no* single surface in the<br>physical object, I would argue.<br><br>&gt; Zones within a surface Figure 3. Zones within a surface<br><br>This text (caption) is misplaced in the output at least. Oh, wait. Is the<br>problem that the image isn't embedded but linked?<br><br>&gt; Zones need not nest within each other; they must however be rectangular, as<br>&gt; previously noted.<br><br>---!!!!! Again, this is a problem that I pointed out before.<br><br>&gt; Alternatively, if the transcription is intended to prioritize representation<br>&gt; of the process by which the document came to take its present form over<br>&gt; representation of the final text , it may be preferable to use a subset of<br>&gt; the available elements and to embed them within the zone element, as further<br>&gt; described in section 11.1.3 Embedded transcription below.<br><br>Smallest point here is that there's an extra space before the comma. More<br>important: This language does not, to my mind, suggest the possiblity of<br>doing strictly diplomatic transcription.<br><br>&gt; Now suppose that we wish to align a transcription of this page with the zones<br>&gt; identified above. The first step is to give each relevant part of the<br>&gt; facsimile an identifier:<br><br>As there's been a paragraph along these same lines added just above, this<br>sentence needs to begin differently.<br><br>&gt; This is the function of the start attribute, which supplies the identifier of<br>&gt; the element containing the transcribed text found within the surface or zone<br>&gt; concerned.<br><br>This needs to acknowledge that (as will probably be usual and at least<br>seems to be true of the example given) the element indicated does not<br>"contain" the text but marks the beginning of the text.<br><br>&gt; An embedded transcription is one in which words and other written traces are<br>&gt; encoded as subcomponents of elements representing the physical surfaces<br>&gt; carrying them<br><br>not all of the elements are "surfaces." Most obviously, &lt;line&gt; and &lt;seg&gt;<br><br>but wait, I was pretty sure that we decided that we *didn't* want to re-use<br>&lt;seg&gt; in this way. I was expecting &lt;block&gt; here<br><br>&gt; patch a part of a surface which was originally physically distinct but was<br>&gt; combined with it at some time prior to some or all of the writing on the<br>&gt; surface.<br><br>Well, I think Elena will better articulate one of my objections here, but a<br>second is that I still don't get why the timing matters. Is it not a &lt;patch&gt;<br>if I affix it last?<br><br>&gt; @binder&nbsp;&nbsp;&nbsp; describes the method by which a patch is or was connected to the<br>&gt; main surface<br><br>but a "binder" isn't a method. Instead of "method" how about one of these:<br><br>instrument device property apparatus<br><br>&gt; @flipping&nbsp;&nbsp;&nbsp; indicates whether the patch is attached and folded in such a way<br>&gt; as to provide two writing surfaces<br><br>I think I have a better name: @hinged<br><br>&gt; The elements surface and zone were introduced above, .<br><br>Typo (superfluous comma)<br><br>&gt; Walt Whitman archive<br><br>Cap on "Archive"<br><br>&gt; editor may wish to assign a set of alterations (deletions, additions,<br>&gt; substitutions, transpositions, etc.) or any other act of writing to a<br>&gt; particular change, to indicate both that one or more of such phenomena<br>&gt; preceded or followed another and also to indicate that they are related in<br>&gt; some way, for example that one is a consequence of the other.<br><br>Same objection that I registered above (and have before, on the list):<br>These need not be time-located, right?<br><br>&gt; &lt;listChange&gt; groups a number of change descriptions associated either with<br>&gt; the creation of a source text or with an encoded text.<br><br>Should be<br><br>&lt;listChange&gt; groups a number of change descriptions associated with the<br>creation of either a source text or an encoded text.<br><br>or something very similar<br><br>&gt; &lt;change&gt; documents a change or set of changes made during the production of a<br>&gt; source document, or during the revision of an electronic file. 2.5 The<br>&gt; Revision Description<br><br>Up until this point "change" has been used as notionally encompassing the<br>plural, so it's odd to start talking here of "a set of changes."<br><br>&gt; Hence, having a certain order of stages put in place before transcription<br>&gt; begins, will allow the encoder to reduce verbose tagging,<br><br>Small point: incorrect comma between subject and predicate<br><br>&gt; A nested listChange elements is also useful to indicate a partial ordering of<br>&gt; revision campaigns.<br><br>Should be either "Nested listChange elements" or "A nested listChange<br>element"<br><br>&gt; Note first, that a change<br><br>Another unnecessary comma<br><br>&gt; initially it takes place in the second stage, but is fixated as a whole in<br>&gt; the third.<br><br>"fixate" is not right here. Should be "but is fixed as a whole in the<br>thired" vel sim.<br><br>&gt; From the documentary perspective, the stage assignments describe the writing<br>&gt; process, in that they specify, which segment has been written when and how<br>&gt; often.<br><br>no comma after "specify"<br><br><div></div></font>