[
Lists Home |
Date Index |
Thread Index
]
Bill de hÓra wrote:
> Alaric B Snell wrote:
>
>
>
>> You can have an entire SAX pipeline without a single byte of XML; a
>> database backend that emits SAX events 'faking' an XML document that
>> goes into an XSLT engine that outputs a string of HTML. No XML
>> actually involved! There's a conceptual 'virtual' XML document that
>> exists between the database and the XSLT engine, but no pointy
>> brackets were harmed in its construction :-)
>
> What would that virtual XML document be encoded in?
It's not strictly *encoded* in anything.
In some implementations there may actually be some data structure that
exists in-memory to hold the result of the database query 'buffered'
until the SAX ContentHandler handles it, but in many implementations,
the query handler loop in the SQL engine would, whenever it had
generated a row of the result, fire off a sequence of SAX callbacks
along the lines of what you might get from parsing the following XML
fragment:
<row index='153'>
<field name='Name'>Alaric Snell</field>
<field name='Email Address'>alaric@alaric-snell.com</field>
<field name='Score'>53</field>
</row>
Now, if the query was just pulling rows from a table, then you could
consider the query engine as 'parsing' that table (a binary data file on
disk) into SAX, but if that's the result of a query such as:
SELECT players.Name, players.Email\ Address, SUM(awards.points)
FROM players, awards
WHERE awards.userid = players.userid
GROUP BY players.Name, players.Email\ Address;
...then you're making up those Score fields as the result of a
computation, so the virtual document has never really been encoded, by
most definitions of the term.
Even more so if you do "SELECT RANDOM() FROM ..." :-)
>> All the guy is proposing to expand upon is the idea that element and
>> attribute content be optionally presented by the SAX API as native
>> values, where the SAX parser has enough information to do so.
> Why does this need to be done within SAX?
It doesn't *need* to be done, it just might be *nice*. In many
situations, the SAX event source might happen to know the types of
things its dealing with and, in some cases, it's easier for the SAX
parser and the application to just pass the data value across rather
than converting it to text and back again in-memory. But as long as you
are dealing with data that can be represented as text, then it's always
possible to exchange it as text and you don't need to do otherwise.
> Bill de hÓra
ABS
|
