Lists Home |
Date Index |
- From: "Rick Jelliffe" <email@example.com>
- To: <firstname.lastname@example.org>
- Date: Wed, 11 Nov 1998 04:00:51 +1100
> 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
* 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
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
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)