>> A byte string is described like this:
>> <element name=”foo” type=”string”
>> dfdl:encoding=”bytes”
dfdl:lengthKind=”fixed” dfdl:length=”17”/>
I am not sure if dfdl:encoding=byte
is the correct way to model opaque blob of data which may not be a string
but complex structure containing mixture of text and binary data and that
structure blob may have alignment requirements within the memory layout.
I believe the correct way to model blob is really the hexBinary or
base64binary - these types do describe the encoding and by default you
would specify the length in terms of number of bytes which could be described
through length facet.
The example HexBinary Type provided
in section 7.2
When you model something as hexBinary,
it is wrong to say the representation is text because data represented
through hexBinary may not be string at all ( could be a complex structure)
and the DFDL representations given below in the example would not be correct.
The example provided by Simon was simple where the data just happened to
be string data.
>> Suppose we wanted to model this
same data logically as a hexBinary 'blob'.
>> <element name="d"
type="hexBinary" dfdl:representation="text"
dfdl:encoding="utf-8"
dfdl:length="11"
dfdl:lengthUnitKind="characters"/>
In some respect having dfdl:encoding=byte
and making it not sensitive to character encoding, we are simulating what
hexBinary specifies already.
Question : Why promote an additional
DFDL specific construct when it could be catered through built-in schema
type?
PS: I am not against having dfdl:encoding=byte
as specified in the spec but promoting it as a mechanism to model opaque
binary data will not rest well with XML Schema folks.
Suman Kalia
IBM Toronto Lab
WebSphere Business Integration Application Connectivity Tools
Tel : 905-413-3923 T/L 969-3923
Fax : 905-413-4850 T/L 969-4850
Internet ID : kalia@ca.ibm.com
----- Forwarded by Suman
Kalia/Toronto/IBM on 08/16/2007 08:49 AM -----
| Mike Beckerle <beckerle@us.ibm.com>
Sent by: dfdl-wg-bounces@ogf.org 08/10/2007 03:26 PM |
|