OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] SAX for Binary Encodings (SAD-SAX)

[ 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 

<row index='153'>
   <field name='Name'>Alaric Snell</field>
   <field name='Email Address'>alaric@alaric-snell.com</field>
   <field name='Score'>53</field>

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



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS