I thought the Oxygen release had fixed that? Oh well, if it's gone now, then good. Cheers, Martin On 15-09-28 08:31 AM, Hugh Cayless wrote:

Something about "xsl:dummy-for-xmlns" something-or-other. None of my ODD files nor Guidelines sources have validated for months. Looks like they do now though.

...

On Sep 28, 2015, at 9:53 , Martin Holmes wrote:

On 15-09-28 06:15 AM, Hugh Cayless wrote:

...

Incidentally, I’ve just pushed a change to the Stylesheets that I think will fix the goofy ODD validation error we’ve been seeing. Didn’t seem to break any tests.

What was the ODD validation error you were seeing? I haven't seen it myself.

Cheers, Martin -- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

Thanks for the corrections, Lou. That’s very helpful. I’ll nitpick back at just one of them below...

On Sep 28, 2015, at 11:40 , Lou Burnard wrote:

On 28/09/15 14:15, Hugh Cayless wrote:

...

I will be integrating the new critical apparatus changes later this morning. Just a few nit picking comments on these:

1. The original reading

marked by an <gi>app</gi> element; each reading is given in a <gi>rdg</gi>element; if it is - desired to single out one reading as preferred, it may be tagged <gi>lem</gi>:

was chosen after prolonged agitation from TEI users who didn't believe in "lem" as distinct from "rdg". The proposed revision is

marked by an <gi>app</gi> element; the preferred (or base) reading is tagged with <gi>lem</gi>; + each reading is given in a <gi>rdg</gi>element:

This renegues on our earlier decision by implying that a lem is required. I think this revision should probably just be reverted.

This is in the section on parallel segmentation. I do obviously agree that a <lem> isn’t *required*, but I think the current prose pushes it too much into the background. You *should* mark a reading as belonging to the base text, partly because otherwise there’s no basis other than order for choosing which one to display in your text, but mainly because you should not pretend that you don’t have a base text. You do unless every single word is part of an app entry. I would argue that it’s best practice to use <lem> for most editions and that therefore it should come first—though I’m happy to note that it’s optional.

2. "Textual variation may manifest in many ways." I think "manifest" needs an object: insert "itself" before "in many ways".

3. "An omission in on witness may" -> "An omission in one witness may"

4. "are a harder phenomenon" -> "are harder" or "constitute a harder phenomenon" (to avoid plural verb with singular complement)

5. The additional constraints in <ab> etc. remind me of why this whole thing makes me feel uneasy: because we really want to do constraints on *members of the class model.pLike* but the architecture doesn't permit it. I have no solution to propose though.

I feel the same. It’s hideous. I like that it’s hideous though, because I hope that will spur us to fix it.

...

Does anyone need help getting their work merged into master before Thursday? Please let me know!

I need a reminder of how to do "svn up" :-(

git pull origin master (though it sounds like you already figured it out)

...

Incidentally, I’ve just pushed a change to the Stylesheets that I think will fix the goofy ODD validation error we’ve been seeing. Didn’t seem to break any tests.

What error? The only change I can see is something to do with namespaces in schematron rules -- is that the one you mean?

Yeah, I stopped it putting the xsl namespace in Schematron files.

-- tei-council mailing list tei-council@lists.tei-c.org http://lists.lists.tei-c.org/mailman/listinfo/tei-council

PLEASE NOTE: postings to this list are publicly archived

I think it’s perfectly possible to not have a base text, what confuses me is how you’d do that with parallel segmentation where not all words are in an <app>. The words not in an <app> are manifestly part of a "base text" whether you believe in that or not. What I don’t understand is how there can be a base text *except* inside <app> (though granted, there might be simple cases where you could do it). Put another way, I don’t think you should be using parallel segmentation if you don’t want to have a base text. You should be encoding all your sources and linking them. You’re quite right though that this isn’t the venue for tilting at this particular windmill. :-) My only concern is that the current wording comes close to recommending against using <lem> and it should be pushed back a bit in the other direction. I’ll see if I can improve on it.

On Sep 28, 2015, at 13:01 , Lou Burnard wrote:

The trouble is that this wording asserts your (perfectly defensible but controversial) opinion on a topic without leaving space for dissent. Some people (I am told) don't agree that the concept of "a base text" makes much sense. Why *should* (your stars) I choose to privilege one of my readings as the base for the others? Why shouldn't I opine that there's no base text? And I don't need to mark every word as part of an app entry in that case : the words that are not part of an app entry are common to all witnesses.

But we shouldn't really be having this fight here: I am only arguing for retaining the status quo. If you want to say something like "if, as is often the case, one reading is regarded as the preferred or base reading, then it should be marked using <lem> rather than <rdg>" I'll shut up.

I suspect it’s a question of perspective. More modern source materials probably make this possible, but I’d consider it a very dangerous assumption to imply the partial identity of a range of sources. There are always differences that are elided by the transcriber/editor because they don’t consider them significant. But then you’re in the position of asserting that you can display the entire reading of #A or #B based on the source, where in fact you’re displaying a derivative, constructed thing + the readings of #A or #B—not simply the transcriptions of one or the other. I think in cases like the libretto example you sent me, you’re in good shape because you have only a few, easily compared examples. My head’s in the space of something like the Propertius example, where you’d be nuts to claim you could present anyone with just the reading of a particular witness across the whole text—again, because the text is the product of the editor’s decisions rather than a merge of all witness transcriptions. If this was simple, we’d get bored! :-)

On Sep 28, 2015, at 13:41 , Raffaele Viglianti wrote:

You could say that all the words (soon to be all textual structures?) outside of <app> are common to all sources surveyed, but you decide not to pick a best reading (the lemma) when the sources disagree, you simply document that they do not agree with multiple <rgd>s.