Hi Bryan,
> To me the best part of your question is your clarifying
> statement that overlapping span of information is infrequent. The problem is that some of those markers are placed by end-users (like comments) not tools, so there is no predictability associated with how frequent they would be.
> Since this is *hopefully* an uber-fringe case. I my preference
> is for A). I know this is causes overhead for the processor and > (in the cases where to processor has not shielded the translator)
> for the translator. This would mean the different elements making up a single span would need so unique id associating them together, as just two elements of the same type may not mean a single span. Note that this complicate things for XSLT-based processor too, not just DOM/StaX based processor.
> But I fear a slippery slope if we (re)start using > <begin /> and <end /> elements. I'm afraid there is no way to not provide those, as the root problem is a shortcoming of XML itself: it just does not handle overlapping spans well, and that is not an un-common type of construct in documents. Note also that such the issue is not only needed for overlapping spans, but also for spans cut by segment breaks. As a devil's advocate I'll say it: The question is going to keep coming: If we must provide a <start/>/<end/>-type of mechanism, it will be part of the constructs that all tools must understand. If all tools must understand that mechanism, why provide another one? -ys
