<br><font size=2 face="sans-serif">Can anyone recall the use case driving
the need for encoding="bytes". </font>
<br>
<br><font size=2 face="sans-serif">I've been trying to reconstruct it and
I am not able to. It was supposedly for using string literal syntax to
discuss padding fields and constant data found surrounding binary data.</font>
<br>
<br><font size=2 face="sans-serif">The spec now has % as the hex escape
for string literals, and the bytes specified using it are not subject to
character set translation.</font>
<br>
<br><font size=2 face="sans-serif">So, if you mean the data has an initiator
that contains hex 6B followed by hex 2C, and you don't know nor care what
characters those correspond to, then just write "%6B%2C". You
don't have to deal with character set encodings at all. </font>
<br>
<br><font size=2 face="sans-serif">So, I can't see why we need encoding="bytes"
anymore. </font>
<br>
<br><font size=2 face="sans-serif">...mikeb</font>
<br>
<br>
<br>
<br><font size=2 face="sans-serif">Mike Beckerle<br>
STSM, Architect, Scalable Computing<br>
IBM Software Group<br>
Information Platform and Solutions<br>
Westborough, MA 01581<br>
direct: voice and FAX 508-599-7148<br>
assistant: Pam Riordan <br>
priordan@us.ibm.com
<br>
508-599-7046<br>
<br>
</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Suman Kalia/Toronto/IBM@IBMCA</b>
</font>
<p><font size=1 face="sans-serif">08/16/2007 08:54 AM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">dfdl-wg@ogf.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td><font size=1 face="sans-serif">Mike Beckerle/Worcester/IBM@IBMUS</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">Fw: [DFDL-WG] Proposal - simplifying
opaque types</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br><font size=2 face="Arial">Sorry I could not call-in yesterday as I
had conflict with another meeting. Here are my comments on the proposal</font>
<p>
<p><font size=2 face="Arial">>> A byte string is described
like this:</font>
<p>
<p><tt><font size=1>>> <element name=”foo” type=”string”
</font></tt>
<br><tt><font size=1>>> dfdl:encoding=”bytes”
dfdl:lengthKind=”fixed” dfdl:length=”17”/></font></tt>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif">The example HexBinary Type provided
in section 7.2 </font>
<br>
<br><font size=2 face="sans-serif">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.</font>
<br>
<br><font size=2 face="Arial">>> Suppose we wanted to model this
same data logically as a hexBinary 'blob'.</font>
<p><tt><font size=1> >> <element name="d"
type="hexBinary" dfdl:representation="text" </font></tt>
<br><tt><font size=1>dfdl:encoding="utf-8" </font></tt>
<br><tt><font size=1>dfdl:length="11" </font></tt>
<br><tt><font size=1>dfdl:lengthUnitKind="characters"/></font></tt>
<br>
<br>
<br><font size=2 face="sans-serif">In some respect having dfdl:encoding=byte
and making it not sensitive to character encoding, we are simulating what
hexBinary specifies already.</font>
<br><font size=2 face="sans-serif">Question : Why promote an additional
DFDL specific construct when it could be catered through built-in schema
type? </font>
<br>
<br><font size=2 face="sans-serif">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. </font>
<br>
<br><font size=2 face="sans-serif"><br>
Suman Kalia<br>
IBM Toronto Lab<br>
WebSphere Business Integration Application Connectivity Tools <br>
Tel : 905-413-3923 T/L 969-3923<br>
Fax : 905-413-4850 T/L 969-4850<br>
Internet ID : kalia@ca.ibm.com</font>
<br><font size=1 color=#800080 face="sans-serif">----- Forwarded by Suman
Kalia/Toronto/IBM on 08/16/2007 08:49 AM -----</font>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Mike Beckerle <beckerle@us.ibm.com></b>
</font>
<br><font size=1 face="sans-serif">Sent by: dfdl-wg-bounces@ogf.org</font>
<p><font size=1 face="sans-serif">08/10/2007 03:26 PM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">dfdl-wg@ogf.org</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[DFDL-WG] Proposal - simplifying opaque
types</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><font size=2 face="sans-serif"><br>
Please review for discussion on a future call.</font><font size=3> <br>
<br>
<br>
</font><font size=2 face="sans-serif"><br>
Mike Beckerle<br>
STSM, Architect, Scalable Computing<br>
IBM Software Group<br>
Information Platform and Solutions<br>
Westborough, MA 01581<br>
direct: voice and FAX 508-599-7148<br>
assistant: Pam Riordan <br>
priordan@us.ibm.com
<br>
508-599-7046<br>
</font><tt><font size=2>--<br>
dfdl-wg mailing list<br>
dfdl-wg@ogf.org<br>
http://www.ogf.org/mailman/listinfo/dfdl-wg</font></tt>
<br>