Re: EXI LC Comments

Is it possible, even using the special codec provisions, to convert
integer and floating numeric values to their straightforward binary
representation for transmission and then back to XML after reception?


Stan Klein




On Mon, December 29, 2008 1:51 pm, Tatu Saloranta wrote:
>
> On Mon, Dec 29, 2008 at 1:23 AM, Daniel Peintner
> <daniel.peintner@gmail.com> wrote:
>>
> ...
>> We feel that EXI should fit smoothly into the XML stack. To avoid any
>> problems EXI supports type information in the same fashion as XML
>> does. The groups intention is not to super-set XML. XML allows one to
>> specify typed-values with the attribute xsi:type. EXI provides the
>> same mechanism and both work on elements only.
>
> While this is true for fully data-based (schema-first, xml-centric
> etc) approach, it is not the only way to handle typing. It is easy to
> infer expected type from application access; that is, if application
> requests content as being of certain datatype (which generally needs
> to be of recognized and pre-defined types, that is, one of XSD types),
> it can be accessed as such.
> There are other ways too, such as inferring schema binding from object
> types, but that only works for statically typed languages.
>
> In case of textual xml for example, this just means that textual
> content is transferred as text, but parser/generator can deal with
> conversions to and from external types: the obvious example is that of
> automated base64 encoding (when writing) and decoding (when reading).
> This can be thought of as variation (or application) of "duck typing":
> instead of requiring a static schema definition, equivalent
> information (or at least subset of) can be provided by access through
> the interface (I realize EXI does not specify API, just encoding
> aspects)
>
> For what it is worth, this is the approach taking with "typed access
> API" for stax2 extension API.
> For EXI perhaps it could be used as a way to generate necessary schema
> information when generating (writing) content; and on receiving end,
> figuring out which if any conversions are needed between raw/native
> data format and format applications wants to use. I don't know if
> this would even fall within scope of what EXI tries to do.
>
> I don't claim that it would be feasible to consider such an approach
> for EXI (both due to timing and since EXI does not define API level
> aspects), I just wanted to mention that there's more than one way to
> slice the cake. Not everything has to be handled at XML level.
>
> -+ Tatu +-
>


--

Received on Monday, 29 December 2008 20:07:02 UTC