[DFDL-WG] Action 275 - Updates to Experience 3 (Bit Order) document

[Mike Beckerle]

Thanks for spotting this. I forget the fine details we have already covered
very often.

So no change to the experience doc on bit-order is needed about this.
However, I just uploaded new versions because somehow the broken references
(due to cut/paste errors no doubt) to sections 34: Appendix D: DFDL
Standard Encodings (spotted in public comment review) snuck past me also.

Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
www.tresys.com
Please note: Contributions to the DFDL Workgroup's email discussions are
subject to the OGF Intellectual Property Policy
<http://www.ogf.org/About/abt_policies.php>


On Tue, Feb 3, 2015 at 7:58 AM, Steve Hanson <smh at uk.ibm.com> wrote:

> Mike
>
> I believe that section 13.7.1.2 1.1.1.1 *Bit strings, Alignment, and
> dfdl:fillByte* already addresses this:
>
> *Corresponding bits from the dfdl:fillByte value are used to fill in
> unspecified bits of the data stream. That is, if bit K (K will be 1 or
> greater, but less than or equal to 8) of a data stream byte is unspecified,
> its value will be taken from bit K of the dfdl:fillByte property value.*
>
> Regards
>
> Steve Hanson
> Architect, *IBM DFDL*
> <http://www.ibm.com/developerworks/library/se-dfdl/index.html>
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK
> *smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:+44-1962-815848
>
>
>
> From:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To:        "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
> Date:        29/01/2015 23:14
> Subject:        [DFDL-WG] Action 275 - Updates to Experience 3 (Bit
> Order) document
> Sent by:        dfdl-wg-bounces at ogf.org
> ------------------------------
>
>
>
>
> I have modified this document per the public review comment.
>
> There are minor changes here which should be brought over to the main
> specification. These changes should be incorporated into the corresponding
> sections of the main DFDL spec such time as we respin that.
>
> There is one stipulation which should be discussed.
>
> When changing from one bit order to another, the document says that this
> happens on the next byte boundary, hence, there is a partial byte that is
> lost to this byte alignment. The public commentor suggested we specify what
> these bits are filled with when unparsing. The DFDL spec is clear about
> filling for whole bytes, but when parts of a byte must be filled there are
> three choices
>
> 1) partial bytes are filled with 0
> 2) partial bytes are filled from the fillByte in some unspecified way
> 3) partial bytes are filled from the fillByte in a specific way.
>
> Consistent with the rest of the DFDL Spec, I took a shot and put
> clarifying language in that says the fillByte is used, but not specifying
> details on exactly how the fillByte's bits are used.  However, the more
> general issue is there independent of the bit-order issues. The description
> of alignmentFill regions and how they are filled does not say anything
> about partial bytes.
>
> A clarifying sentence in the table for the dfdl:fillByte property should
> probably say "When unparsing, if a region being filled is a partial byte,
> then it is filled with bits taken from the value of the dfdl:fillByte
> property in an implementation-specific manner."
>
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
> *www.tresys.com* <http://www.tresys.com/>
> Please note: Contributions to the DFDL Workgroup's email discussions are
> subject to the *OGF Intellectual Property Policy*
> <http://www.ogf.org/About/abt_policies.php>
> --
>  dfdl-wg mailing list
>  dfdl-wg at ogf.org
>  https://www.ogf.org/mailman/listinfo/dfdl-wg
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20150210/5ec27c9e/attachment.html>