Skip to content

Commit

Permalink
the problem of the notes...
Browse files Browse the repository at this point in the history
  • Loading branch information
@HelenaSabel
HelenaSabel committed Oct 28, 2015
1 parent 66e7696 commit 0e1c146
Showing 1 changed file with 2 additions and 1 deletion.
3 changes: 2 additions & 1 deletion XML-and-Schematron/Southey/Southey_Amadis_1803_2.xml
View file
Original file line number Diff line number Diff line change
Expand Up @@ -103,7 +103,8 @@
<anchor ana="start" synch="#M1_p1_c65"/>their religious purposes be overcome,<anchor ana="end"/>
<anchor ana="start" type="add"/>and it<anchor ana="end"/>
<anchor ana="start" synch="#M1_p1_c66"/>should be with them as it was with the Princess Elisena.<anchor ana="end"/>
</note> centered.</s>
</note> centered.</s>
<!-- heb: this word has no anchor-->
</p>


Expand Down

6 comments on commit 0e1c146

@HelenaSabel
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe we should consider the use of <anchor ana="start"> with a @corresp attribute to link it to a particular <anchor ana="end"> for cases like this.
I think the <anchor ana="start" synch="#M1_p1_c43"/> should "end" after "centered" (one word we are missing in our output because is outside of the <anchor> relationships).

@ebeshero
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@HelenaSabel @sydb @setriplette I see it (and sorry for the delayed response, but it's timely now as we are rethinking our use of attributes). So, back up in the file all the way up to line 82 here (just above the note) to see the anchor that points to M1_p1_c43. Helena's proposed use of @corresp here makes a lot of sense, because there is a long series of anchor elements sitting inside that note, and we need a way of jumping over all of them to indicate completion of a translation unit sitting above note level. But to use @corresp for this would conflict with the way we're considering it as a possible replacement for @synch. If we use @corresp to point to "anchor ends" within Southey, we really shouldn't (couldn't) use it to point to Montalvo's xml:ids. I suppose that's a further argument for our project-specific use of an invented @mapsTo attribute.

Our use of <anchor/> elements is most like this example in the TEI Guidelines for boundary marking with empty elements. In order to point to a particular boundary, we're going to have to put xml:ids on the anchors, which adds complexity to our coding and workflow. The other option is to try processing any such starts and ends with XPath in our XSLT processing: to "vault over" any anchor elements inside <note> elements, and look for sequential anchor elements (from start to end) ONLY when they are siblings of each other and not sitting inside the <note> elements.

@ebeshero
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@HelenaSabel @sydb @setriplette Except, now that I think of it, I realize that we must use the preceding:: and following:: axis to seek out our sequential anchor elements, since we're weaving in and out of our markup of Southey's sentences (<s>...</s> elements). The only solution, short of adding xml:ids to each Southey anchor, will be to write XSLT template rules that treat <anchor/> elements separately when they appear in Southey's main text vs. Southey's notes. We know that the passages in Southey's notes will not be continuous with the <anchor/> elements we're marking in the main text. Even if Southey repeats a passage, we would start over in the note by marking where such a passage occurs in Montalvo. I think we should make sure, then, that our XSLT rules process <anchor/> elements in the main text so that they ignore any elements that sit inside the notes. Is there any reason, think you, that this can't be done and we need to put xml:ids in Southey? (Either way is writing more XSLT that will involve having to distinguish between anchors in main text vs. notes--so I suppose I'm preferring the road with the least additional markup!) Let me know what you think.

@HelenaSabel
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Indeed there is no need to add any pointers to the <anchor/> elements because they are at different levels due to the parent . That means that there is no ambiguity. The only thing we need to change is the Schematron rule that doesn't allow "nested" <anchor/> elements so we can have things like:
<anchor ana="start" mapsTo="#Montalvo"/>This is a clause with a word <note>Here Montalvo says: <anchor ana="start" mapsTo="#Montalvo"/>something<anchor ana="end"/></note> that it is annotated<anchor ana="end"/>

@ebeshero
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good! That's a relief. 👍 Okay, it'll be easy enough the change the Schematron rule: I'll go do that. I think that @sydb hasn't pushed his changes to our Schematron yet, but I think we can handle this with a merge. (fingers crossed).

@ebeshero
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha! I just realized I was misreading your initial code, and thought the anchor end was after the <note> already. Of course it's not, because I prevented us from writing that kind of markup. I guess I'm not quite awake yet, even though I'm jet-lagged on Europe time!

Please sign in to comment.