Endtag attributes

[Rick Jelliffe]

> From:   Anders W. Tell

> Im especially interested in arguments for having endtag arguments.

One good reason pro is because when you are doing text processing using a
streaming tool (i.e. one that does not load the document in memory)
sometimes you wish to write out attributes with values collected from
processing sub elements.

Consider an application which reads a table and adds an attribute with the
column and row count.

This is a kind of foward-reference problem. In streaming text processing
tools you:

* have two passes, or
* write out the values of all the attributes in an external entity file (so
that the XML parser resolves the references on next document load), or
* have a built-in reference resolving phase such as OmniMakr uses.

Until recently (and for all I know, maybe still) most text processing of
non-HTML SGML/XML marked-up files was done using streaming tools (i.e. with
event programming).

The trouble with having end-tag attributes for this kind of use is that even
though it would be easier to generate such documents, an end-tag attribute
solution does not buy you anything, because if you are using streaming tools
you will still need the "collected value" attributes when you come to the
start-tag, in order to set up processing of the rest of the element. You
still need some step to move the end-tag attribute to the start-tag.

And, as has been mentioned, maybe people who are used to tag-based text
processing rather than element (i.e. range) based processing will not be
encouraged to alter their thinking, if end-tag attributes were allowed.

Perhaps the one thing that end-tag attributes might be useful for is
checksums, though.

Rick Jelliffe


xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)