From mb@mbeddow.net Thu Sep 20 18:32:29 2001
Date: Wed, 19 Sep 2001 15:50:48 +0100
From: Michael Beddow <mb@mbeddow.net>
To: editors@tei-c.org
Cc: Burnard Towers <lou.burnard@computing-services.oxford.ac.uk>
Subject: P4X Section 14

[comments from Lou]

Report on P4X 14 (Linking, segmentation, and alignment)

A few more problems here than in 12, (which I trust arrived safely)
mostly case-sensitivity-induced.

1) 14.1 passim The enumeration for targOrder is (Y | N | U) but
everywhere this attribute is given a value in the examples it is
lowercase "y".  In the running text (14.1.2, p. 312) the upper case N is
(XML-correctly) used. I could provide a complete list of all the
targOrder="y" instances that need changing, but since a simple
search/replace operation should deal with them, this is probably
superfluous.

[Fixed]

2) 14.1.2. p. 311 Running text reference to "identifier (N3.284)" needs
altering to "n3.284" to match the example.

[OK]

3) 14.1.3  p.312 last para of running text "to avoid having to repeat
the type=imitation" needs quotes on the attribute value.

[OK]

4) 14.1.4 p. 315 Running text "The evaluate=all attribute", attribute
value needs quoting.

[OK]


5) 14.2.1 p.315 In the gloss on the from attribute, delete phrase
"described in section" from end of sentence.

[Formatting error!]


6) A more general point on 14.1.2. This section offers "various methods"
of placing a note at some distance from the text. They are indicated by
paras beginning "First",  "Second", and "Thirdly". Leaving aside the
mismatch of suffix between Second and Thirdly, this implies three
self-contained examples. The problem is that the second example (only)
isn't self-contained. The markup of the note in that example requires
the <l> elements in the poem text to have id attributes for the target
to point to. But in the example of poem text so far shown, they don't.
Such id attributes are present only in the poem text as given in the
example given for the third method. I would suggest that the example
note markup for the second case should be preceded by the same four
lines of sample poem markup (with <l> id's supplied) that are found in
the example for case 3. As well as making the second example properly
self-contained, it would also help the reader to identify more readily
(by comparison of complete examples) the additional markup specific to
the third example, viz the use of a link element, along with the removal
of the ptr element and the deletion of the target attribute of the note.

[OK.]

7) And a pretty marginal quibble. In 14.1.4. p. 315 we find

"When the target attribute of a <ptr> or <ref> element specifies more
than one element, the indicated elements are always understood to be
combined or aggregated in some way to produce the object of the
pointer.2

Fair enough, but at analagous points elsewhere, there is usually some
mention that such "combination or aggregation" is the task of a
processing application, and that the "some way" in which this processor
is expected to operate should be indicated in the teiHeader. The world
is full of encoders who think that entering such markup "makes it so"
and think that applications progammers are being diffucult when they
demur.

[Good point: have revised to read:

  When the <att>target</att> attribute of a <gi>ptr</gi> or <gi>ref</gi>
element specifies more than one element, the indicated elements are intended
to be combined or aggregated in some way to produce
the object of the pointer. (Such aggregation is however the task of a
processing application, and cannot be defined simply by the mark-up).
]

8) 14.2 passim.

The horrible ambiguity of the term "root" in the XML-DOM world rears its
head at a few places. There's a note of the problem inserted into the
remarks on the ROOT keyword at 14.2.2.3, but I'd suggest moving this
forward and putting it maybe at the head of 14.2.2.2, immediately after
the first sentence and before the initial overview list of location
keywords. This would then allow the initial gloss on root to be changed
to "this points to the root element of the target document" instead of
the XML-ishly-troublesome phrase "the root of the target document"  But
this would still leave the somewhat question-begging "i.e"  in para 3 of
14.2.2. (p. 316) "a link to the root (i.e. the document element --- by
default, this is the <tei.2> element) of the document in which it
appears".  I don't claim to have a ready solution here, but I think it
needs a bit more thought, if only because the meaning of "root", like
certain encoding issues, is one that taps into misunderstandings
harboured by people otherwise very well informed about the field.

[OK. Have tried to make usage consistently "root element" to avoid
ambiguity, but the whole thing is moot if we decide (as we shd) to go
to xpointer, &winita;]


9) 14.2 passim

Oh dear. Quite a lot of nit-combing needed here, because so many of the
examples mingle location terms (case insensitive under both regimes)
with attribute values and unparenthesisied generic identifiers (case
sensitive in XML but not necessarily so in SGML), The problem starts
with the example under 14.2.2.3. Since as far as I can see the
Guidelines use either lower or camelCase for element names, the example
needs to become
ROOT DESCENDANT (2 div1)
DESCENDANT (2 div2)

Similar considerations apply to nearly all the many subsequent examples
that use attribute values and generic identifiers (the running text
commentaries on the examples of course use lc for element names and
attribute values, throwing the problem into particular relief there)
The only two examples I can find that can be left as is are in 14.2.3 at
the very top. Bizarrely, the very next example shows another variation,
which, while not an error, is liable to mislead: for some reason (in
this example alone) the ID keyword, used everywhere else,
straightforwardly enough, in upper case, suddenly appears in l.c

<xptr id="x1" doc="doc1" from="id (d1.1)" to="DITTO"/>
<xptr id="x2" doc="doc2" from="id (d2.1) tree (2 *)" to="DITTO"/>

To avoid the perplexed seeking significance where there ain't none, I
strongly suggest that usage here should be conformed to the rest of the
section.

[OK: hunted and tracked down all gis and attnames and lowercased them,
and also made all keywords uppercase]

Would you like me to prepare a list (or some sort of diff) of all the
parts that need changing? 

[No,I think I spotted most of them]

I can't do so right now in a properly checked
way and still meet the deadline, because while doing this I'm also
trying to talk my wife through disabling the alarm on her car somewhere
in the wilds of Northumberland, and my concentration is a bit ragged
(especially as she has to dash 20 metres or so away from the car to hear
each instruction over her mobile, since the alarm is making such a
racket -- makes telephone support for Windows users seem a piece of cake
by contrast)

10) At the end of 14.2.3, the otherwise magnificent XMLiser seems to
have slipped out to lunch while Sebastian's back was turned. Neither of
the two divs in the example is closed, nor are any of the items in the
list (Virgil, Homer, etc) in the first div. Similarly unclosed are the
ptr elements for Curll and  Theobald, and all the link elements in the
following two <linkGrp>s

[Fixed]

The rest seems fine until

11) 14.7 p346
"Note the use of the global n attribute to supply a descriptive name to
distinguish the two virtual <q> elements represented by the <join>
elements; "
But in fact it's the desc attribute that is shown doing this in the
example given, so the running text and the example don't match.

[Homer nodded...]


I think that's it...

Michael

--------------------------------------------------------
Michael Beddow   http://www.mbeddow.net/
XML and the Humanities page:  http://xml.lexilog.org.uk/
The Anglo-Norman Dictionary http://anglo-norman.net/
---------------------------------------------------------


