Chris Little wrote:
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.
I understand the necessity of milestoneable elements. While they do cause challenges for XSLT writers, that is a necessity they have to face.
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.
The nature of the Sword API and JSword is that it grabs one or more verses and presents them to the user. Since the document context (e.g. work element) is not readily available, Sword use the module's conf to carry the module's global meta/control data (e.g. Direction, Global Options, Filters, Language) that is very useful in rendering a verse in isolation. For example, I don't remember seeing xml:lang in the WLC, TR or other works.
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").
With the elimination of <milestoneStart> and <milestoneEnd>, I (perhaps wrongly) understand this that <milestone type='x-start-suchNso'/>...<milestone type='x-end-suchNso'/> is discouraged. According to the OSIS documentation it is to be used as a "point event" marker. Using <milestone type='x-change-script' script='xxx'/> seems to be a variation of using begin and end. I guess it can be argued that it is a point event marker, but I think that there are better mechanisms already in place, but not used. As you suggest below.
Of course, that doesn't solve your problem with writing XSLTs at all. :)
And obviously, even though I don't like your suggestion of using <milestone> to mark a transition from one script to another, it is still equivalent to add the script attribute to a milestoneable element such as <q>. And this we have to be able to handle.
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?
Excellent.
I don't think that it is necessary to mark up every div or seg. Only the ones that differ from the document's norm need the markup.
I would be happy if xml:lang or script were added to <note> elements when it differed from the xml:lang or script of the document.
By the way, I think it would be good for Sword to publish what it sees as OSIS best practices. (I also think it would be good if OSIS would do the same, as it is not explicit.) I understand that this would be a changing set as the standard matures.
_______________________________________________ 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
