[sword-devel] New Accented Greek NT with Morph
chrislit at crosswire.org
Sat Apr 23 09:14:22 MST 2005
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?
More information about the sword-devel