> What did SGML Open say was wrong with <MARK>?
> Did they offer a useable alternative?
> I thought <MARK> would be indispensable for
> stuff like server-side highlighting.
I reproduce their comments:
-- start of quotation
> Asynchronous elements
> Anything that subverts the tree-structuring of an SGML
> document is prone to inconsistencies of implementation and
> behavior. Note that hypertext links do not subvert the
> structure: Although the ends of a link may be parts of
> documents, a link itself is not (obviously if it were, it
> could not reach between different documents). The problem
> cases instead are things like inserting EMPTY elements that
> an application is expected to treat as a span:
> *** This is a very bad idea. ***
> Many optimizations that programs can use because they know
> they are dealing with trees are lost if such structures are
> permitted. For example, a program can no longer tell how to
> format part of a document without going all the way back to
> the beginning, on the off chance there was a <stemph> a long
> way back. Likewise, one cannot easily build a stack-based
> formatter, e.g. that keys styles off the list of element
> types in one's ancestry. An editor is in even worse shape.
> There is no way to validate that such pairs even match,
> because "matching" is not a generic notion -- it has to be
> custom-built for the specific semantics of each kind of
> pair.
> Many DTDs have inserted such element-pairs in their first
> drafts; they end up removing them later, because they prove
> to be a pain for both implementors and users, and to have
> surprising side-effects. We strongly recommend avoiding them
> completely.
> Asynchronous structures do arise, but experience has taught
> that they are far rarer than one might predict. Most cases
> can be dealt with by marking up two pieces separately,
> without loss of expressiveness -- this is fine for the
> emphasis example above. There are important cases this does
> not cover (the TEI has analyzed and described them
> extensively); but there is probably no faster way to wipe
> simplicity and portability from a DTD than to include
> asynchronous elements.
> or truly crucial cases, such as annotation attachment to
> asynchronous selections, a better way is to keep the pointer
> entirely out of line, for example:
> <annot start=3DID1 end=3DID2>
> This form has many advantages: It does not disturb the
> structure or applications that expect to deal with it; it
> can guarantee that the pointers to both ends are present,
> and remain intact despite editing; it keeps the
> representation of both ends together as a unit, which is far
> safer and clearer; it is not prone to disasters arising from
> cut/paste, subset, and other operations that might pick up
> one end and not the other; it is compatible with HyTime
> linking (see the multloc and spanloc devices).
-- end of quotation
The best solution so far (IMHO) was given bby Michael Johnson.
That is to define a SPOT element which exists to allow an ID
to be inserted at a random place in a document. Then you can
do something like:
<range class=search from=spot01 until=spot02>
.
.
.
<spot id=spot01>
.
.
.
<spot id=spot02>
I will add this into the 3.0 proposal. The class attribute on the
range element allows the RANGE tag to be subclassed, and in this
case indicates the range is a region matching some search criteria.
This combined with an ID attribute would provide opportunities for
selectively highlighting ranges based on their class, and customizing
their appearance with stylesheet entries.
-- Dave Raggett <dsr@w3.org> tel: +44 117 922 8046 fax: +44 117 922 8924
Hewlett Packard Laboratories, Filton Road, Bristol BS12 6QZ, United Kingdom