[sword-devel] New Accented Greek NT with Morph

[Chris Little]

DM Smith wrote:
> Personally, I think that <milestone> with x- types should generally be 
> avoided, unless they are standardized by Sword or OSIS. Also, OSIS is 
> removing milestone begin and milestone end. I don't think we should use 
> them for that purpose. Using them for a state change is using them as 
> implicit begin/end markers. My selfish perspective is that milestones 
> that represent a state change in the flow of a document are difficult to 
> handle in XSLT. (Milestones that are truly point in document events, 
> that don't mark the beginning or end, implicitly or explicitly, are not 
> a problem.)

<milestoneStart> and <milestoneEnd> were deprecated when the sID and eID 
attributes were added to milestoneable elements. It's simply a different 
method of encoding the same information. So now you would use <q 
sID="id"/>...<q eID="id"/> instead of <milestoneStart 
type="q"/>...<milestoneEnd type="q"/>. <milestone> itself is still valid 
and approved of.

We could put script information of existing elements if there were a 
consistent way to do that. E.g. we could put one value on every book 
<div> but put other values only on <foreign> elements, but this would 
only work if all foreign strings were actually marked as such. It might 
be possible in some cases to automate this markup, but it would probably 
need some hand tuning to result in valid documents in other cases.

If you JUST want to indicate ranges over which a single script is used, 
one of the general purpose tags is necessary: <seg> or <milestone>. But 
<seg> is not milestonable, so <milestone> would have to be used to cross 
container boundaries that might appear. Using beginning/end (i.e. 
implicit container) semantics with <milestone> is already standard in 
OSIS. Those are the semantics used with the "column", "line", "pb", and 
"halfLife" types (indeed, arguably all types except "cQuote").

Of course, that doesn't solve your problem with writing XSLTs at all. :)

I think the best solution is probably one that involves a good document 
encoder who actually sets the script attribute on container elements 
that already occur in the document (or <seg>s if none occur in some 
instances), which was really the attribute's intended purpose. Do you 
have any better ideas? Or even just any other ideas?

--Chris