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 _______________________________________________ sword-devel mailing list: sword-devel@crosswire.org http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
