From lou@ermine.ox.ac.uk Sun Sep 16 01:27:31 2001
Date: Sun, 16 Sep 2001 01:17:46 +0100 (GMT Daylight Time)
From: Lou Burnard <lou@ermine.ox.ac.uk>
Reply-To: Lou.Burnard@oucs.ox.ac.uk
To: Rafal T. Prinke <rafalp@amu.edu.pl>
Cc: steven_derose@brown.edu
Subject: Re: TEI P4 Review


Dear Rafal

Many thanks for your careful reading and helpful comments!

> I have used the PDF version to be able to refer to pages.
>
> I. General
>
> Some of these things have already been pointed out by others, as
> I have seen on the Web page with their comments, but I will still
> point them out again:
>
> 1. Names of elements in the text are not distinguished in any way.
>    Perhaps the P3 style of angle brackets (and maybe Courier font)
>    should be used?

We fixed the bug that was causing that (I think): please check the new
versions of the PDF files if you have a moment.

>
> 2. Formatting (or rather alignment) of examples is inconsistent
>    in many places. Opening and closing tags should be indented
>    to the same depth if on different lines (I will list those
>    in 20 below, but the same may refer to some other chapters.

As aforesaid, this is a problem we face throughout the text.

>
> 3. Some attribute values in the examples are in lower case while
>    in the DTD they are in Upper Case, as in:
>
>           exact (Y|N|U) "U"
>
>    I guess this may also be a problem in other chapters.

Yes, we need to work out a systematic solution to this.

>
>
> II. Particular
>
> I will use page number and the opening words of the paragraph
> in question (or preceding an example) to identify the place
> on the page. The ">" indicates quotation from P4 and "#" my
> proposed substitution text.
>
> p. 455 - The chapter begins...
>
> > personal names (section 20.1 Personal Names, place names
>
> missing closing parenthesis

whoops: fixed.

>
> p. 455 - The additional tag set...
>
> the structure has too much light before:
>
> <!-- end of [DND]  20.-->
>
> and the same in the next one after:
>
> <!-- [DNDENT] 20.: Additional classes for names and dates -->
>
> In both cases one empty line will be best.

Hmm. The first of these may be caused by a comment in the
source, but I'm not sure what's causing the second one. I've
made a few changes which might fix these formatting
problems...

>
> p. 456 - top
>
> unnecessary empty line after:
>
> <!ENTITY % m.temporalExpr "%x.temporalExpr; %n.dateStruct;
>
> but in the HTML version it is all on one line.
>
> At the end of the same there is no ligth before:
>
> <!-- end of [DNDENT]  20.-->
>
> and probably there should be one empty line (following the conventions
> elsewhere in the text).

As above.

>
> p. 456 - <persName> contains...
>
> > possibly including any or all of the person's forename, surname,
> > honorific, added names, etc.
>
> I think they should all be in plural form:

I suppose so. Do people have more than one surname?

>
> # person's forenames, surnames, honorifics, added names, etc.
>
> p. 456 - <nameLink> contains...
>
> > such as van der or of.
>
> should be:
>
> # such as "van der" or "of".
>
> That's how it is on p. 458 (bottom).

Yes. Actually this is an ODD processing error.

>
> p. 457 - The persName element may be used...
>
> > synonymous with the tag <name type=person>
>
> attribute value should have quotation marks:
>

Whoops. Fixed.


> # synonymous with the tag <name type="person">
>
> Also the font size used in PDF is too big (not in HTML).
>
> The example following that paragraph is not formatted correctly.

Fixed (well, improved)
>
> p. 457 - Many cultures distinguish...
>
> In the second example after that paragraph:
>
>   <foreName>Franklin</foreName>
>
> should be moved one character to the right.

Fixed

>
> p. 457 - The type attribute may...
>
> In the example:
>
>    <surname type="last">Roosevelt</surname>
>
> Isn't this a tautology? There may perhaps be "last surname" when
> a person has more than one - but this is not the case in this
> example.

>
> In the same:
>
>    <foreName type="Christian">Margaret</foreName>
>
> Should "Christian" be capitalized here? I would assume that
> "Christian" is contrasted with "pagan", "Moslem" etc.,
> while "christian" means "baptismal".

Good point. Actually, I've no idea whether Baroness T. was baptised. Just
for fun, I've revised this as:

  <foreName type="given">Margaret</foreName>
  <foreName type="abbrev">Maggie</foreName>

>
> p. 458 - In most cases, patronymics...
>
>   </persName> should be aligned with the opening tag
>
> ***** OK - I will not list all of the other similar misalignments ****

We'll have to track em down though...


>
> p. 458 - When a patronymic...
>
> I think the example may end with:
>
> > artificiality of the procedure.
>
> as the rest with its markup may be misleading.

OK

>
> p. 458 - Some names include...
>
> > such as ^Junior^ or ^senior^
>
> Shouldn't the capitalization be consistent here?

Yes. I've changed "senior" to "the Elder"

>
> As the "dynastic information" is mentioned, it might be helpful
> for the users to extend the royal example to include
> the name of the dynasty - eg. "Rudolf II Habsburg".
> I must say that I am not sure how to encode this -
> perhaps "Habsburg" should be treated as <surname>
> with type="dynasty"? In that case, the term "dynastic" in
> the text is misleading because kings/queens are numbered
> irrespective of the dynasty.

I've added

<persName>
  <foreName>Rudolf</foreName>
  <genName>II</genName>
  <surname type="dynasty">Hapsburg</surname>
</persname>

I don't quite follow your logic: the dynasty name is nothing to do with
the gen-name.

>
> p. 459 - Finally, the addName...
>
> I think it would be good to explain in this paragraph that
> <roleName> does not (or does it?) cover roles in an event,
> such as "witness" or "defendant". Perhaps a proper way to
> encode such roles should also be indicated here.

Good idea. I've added the following text after the reference to the
Hammer:

"Note, however, that the <term>role</term> a person has in a given
   context (such as <mentioned>witness</mentioned>,
   <mentioned>defendant</mentioned> etc. in a legal document) should
   not be encoded using the <gi>roleName</gi> element, since this is
   intended to describe the role of this part of the name, not the
   role of the person bearing the name. "

I agree with you that there ought to be some simpler way of marking the
things like "John the Baker", or "Fred, defendant". But this
needs more careful consideration, and possibly a major revision of the
text .

>
> p. 459 - A name may have...
>
> In the example (misaligned line):
>
> >  <addName type="nick">Jerry</addName>
>
> I think it should rather be:
>
> #  <foreName type="nick" reg="Jeremiah">Jerry</addName>
>
> or something like this, as "Jerry" is a diminutive form
> of a forename, rather than a nickname as such.
>

I'm not so sure about this. For one thing, "Jerry" is actually short for
"Gerald" in this case, but more significantly, a nick name can be an
abbreviation too. If you wanted to be picky you might tag it as
<forename type="nick"><abbr reg="Gerald">Jerry</abbr></foreName> I
suppose.



> p. 460 - Like other proper...
>
> > with the name element.For cartographers
>
> Missing space after fullstop.

Whoops. Fixed.

>
> > They also provide importance evidence
>
> # They also provide important evidence

Whoops. Fixed.
>
> > to be encoded, the placeName> element
>
> The closing bracket - but, as noted above, all element names
> should be in angle brackets. If they are inserted, this one
> may be doubled. Anyway, it is a typo.

Whoops. Fixed.

>
> p. 461 - Additionally, all of the above...
>
> No explanation of "type" and "full" attributes - I think
> they should be there, even if they are so often repeated.
>

Aaargh! This is a processing error, which ought to show up elsewhere too.

> p. 461 - Like the persName element...
>
> >  <name type=place> or <rs type=place>
>
> #  <name type="place"> or <rs type="place">
>
> and smaller font size in PDF.

Formatting problem. On the list.

>
> A short note below starting "Strictly, a suitable value..." looks
> strange. The font is very small and it comes after the colon ending
> the previous paragraph. Maybe it should go as normal text *after*
> the example?
>

It should be a footnote, but was wrongly tagged in the source.

> p. 461 - As indicated above...
>
> > (see section 20.2.1 Geo-political Place Names )
> > (see section 20.2.2 Geographic Names )
> > (see section 20.2.3 Relative Place Names .
>
> Unnecessary space before closing parenthesis and missing
> parenthesis in the last case. The spaces are OK in HTML.

Not sure where the extra space is coming from. Looks like a formatting
error. Added closing paren.

>
> p. 462 - For example...
>
> A few unnecessary spaces before "Mississipi River".

Fixed

>
> p. 462 - All the place name...
>
> > phrase indicating the the position
>
> # phrase indicating the position
>
> And missing fullstop at the end of the paragraph.

Whoops! fixed.


>
> p. 463 - top example
>
> >   <distance exact="u">10 miles</distance>
>
> The "u" should be "U" as in the DTD.
>

Well spotted!


> p. 463 - The internal structure...
>
> > using feature structures 16 Feature Structures .
>
> # using feature structures (16, Feature Structures).
>
> ie. missing comma and parentheses, and unnecessary space.

OK.

>
> Also, the font size of the next line seems slightly bigger.
>
> p. 464 - Like names of persons...
>
> > parts of an organization names may give crucial clues
> > which help to characterizing the organization
>
> # parts of an organization name may give crucial clues
>                            ^^^^
> # which help to characterize the organization


Fixed

>                 ^^^^^^^^^^^^
> p. 464 - The orgname element...
>
> "orgname" should be "orgName" (twice in this paragraph).
>
fixed

> Also the example following is *very* misformatted
> (OK. I said I wouldn't mention it).

Fixed, a bit.

>
> p. 465 - Like the rs and name...
>
> orgname -> orgName
>
OK

> (next paragraph:)
>
> orgtitle -> orgTitle

OK

>
> p. 465 - Organization names may...
>
> approprate -> appropriate

OK

>
> (the same paragraph:)
>
> > place name tags 20.2 Place Names .
>
> # place name tags (20.2, Place Names).
>
> ie. space, comma, parentheses.
>
OK

> p. 465 - The orgtype element...
>
> orgtype -> orgType
>
> The example following this may well end with "delibertation."

Well maybe. But it's quite nice to read! I changed the <emph> to <hi>
though.

> p. 466 - Organizational names may...
>
> orgdivn -> orgDivn

OK
>
> Also unnecessary space before "Department" in the example.

OK

>
> p. 466 - Although highly flexible...
>
> > feature structure notation is recommended 16 Feature Structures
>
> # feature structure notation is recommended (16, Feature Structures).
>
> ie. comma (is in HTML), parentheses, missing fullstop, possibly space
> at the end.

OK

>
> p. 466 - The formal declaration...
>
> In the PDF version (but not HTML) the name "orgTitle" in the
> first ELEMENT declaration is hyphenated (and certainly shouldn't).

Formatting problem. To be investigated!

>
> More importantly - the expanded definition of "orgName" as generated
> by the Pizza Chef (today!) has the "#PCDATA" as the last element
> in the content model definition and doesn't parse. It seems to be
> correct in the Guidelines text, however.

This is one of those bugs that just won't lie down. It's because the
Pizzachef is *STILL* using an old version of the XML extension file, and
I've been too busy with P4X to modify it to use the more recent DTD
fragments (now that we have real XML DTD fragments, I have
to undo the cunning kludge I put into the chef to make it use the non-XML
versions, which requires approx 100 nanoseconds thought and is therefore
proving impossible to schedule...)

 > > p. 467 - <hour>...
> > > <hour> the hour component of a temporal expression such as
>
> # <hour> the hour component of a temporal expression.
>
> p. 467 - As members of the class...
>
> Missing "type" and "reg" explanations?
>
> p. 467 - An absolute temporal...
>
> > a sequence of day, month week, year or occasion elements,
>
> # a sequence of day, month, week, year or occasion elements,
>
> ie. comma after "month".

OK

>
> p. 468 - The occasion element...
>
> In the example the two <dateStruct> values are:
>
>    "1-1" and "4 July"
>
> While it is up to the user which convention he/she/it
> chooses, using two different conventions in one sentence
> is certainly not a good practice and should not be
> found in an example.

Agreed. Fixed.

>
> p. 468 - Absolute temporal expressions...
>
> In the example, perhaps a fullstop might be used
> after </timeStruct> - in both parts - to end
> the sentence.

OK. You dont like colons?

>
> p. 469 - The element distance...
>
> > using a occasion element
>
> # using an occasion element
>

OK

> Also, three hyphens turned into one long dash in PDF.

Removed. Also changed "endlessly recursive" to "deeply nested"

>
> The 4 examples after that paragraph all have lower case
> attribute values "u" and "n".

OK

>
> p. 470 - top
>
> The first and second paragraphs seem to have different font sizes.
>
Looks OK to me now

> In the second, a space after "Mechanisms ."
>
> Finally - pp. 471-472 are missing from the PDF version. I assume
> 471 has the rest of the text on 470, and probably 471 is blank?
>
This was a slip in the first version of the PDF file: it's OK if you look
now.

>
> Well... hope this helps.

Very much so! Many thanks again!

>
> Best regards,
>
> Rafal
>


