Re: A17: keep or drop entities?

On Thu, 10 Oct 1996 DAVEP@acm.org wrote:

> Many processors rely on the SDATA designation to trigger the special
> handling.  Leave it out and we're in trouble.

OmniMark, for instance, uses the SDATA label. 

I'd suggest that usually SDATA entities are used as keys into a table of
entities known by a public identifier (with ENTITIES in the identifier). 
Often these entities are single characters or glyphs. 

So, rather than getting rid of SDATA, perhaps it should be promoted as
the way to signify this kind of indexing, with a view to allowing fast 
access to large internal-form (e.g. already in a grove or in a database)
tables of data.

Under this view, name qualifications could be added to XML and ISO8879
without much pain:  e.g.  &ISOlat1:eacute;  meaning 'lookup in table keyed
by "ISOlat1" the text keyed by "eacute"'.   This mechanism would
also allow convenient access to other simple databases apart from lists 
of characters/glyphs, which XML system creators might find useful. 
E.g. 
<table><row><cell>Today's price</cell>
<cell>&DowJones2334:XmlCorp;</cell></row>
<row><cell>Yesterday's price</cell>
<cell>&DowJones2333:XmlCorp;</cell></row>
</table>

It would also be useful for getting glyphs, and any case where the
number of SDATA entities might be in the tens or hundreds of thousands
(i.e. where the SDATA mechanism is tedious and inefficient, but where
a query mechanism is overkill):
<p>The Chinese character for hamburger is &CMAC:C12344;.</p>


Rick Jelliffe            http://www.allette.com.au/allette/ricko
                         email: ricko@allette.com.au
================================================================
Allette Systems          http://www.allette.com.au
                         email: info@allette.com.au
10/91 York St, 2000,     phone: +61 2 9262 4777
Sydney, Australia        fax:   +61 2 9262 4774
================================================================

Received on Friday, 11 October 1996 02:00:26 UTC