Steve, Please add this point to the agenda for next week. We have to revisit this errata given the 7-bit character encoding. (And, I've discovered now there are legacy 6-bit as well which do come up.) ...mikeb On Mon, Nov 26, 2012 at 10:32 PM, Mike Beckerle <mbeckerle.dfdl@gmail.com>wrote:
We also need to decide on Errata 2.95 which is about whether text is implicitly 8-bit aligned.
Given that we have cases of text aligned in other ways (the 7-bit packed ascii stuff), this rule seems heavy handed and inflexible.
We could say that if alignment="implicit", then the first codepoint of any text is implicitly aligned on an 8-bit boundary. This would apply to delimiters, but also to any text that is being scanned with a regex. Subsequent codepoints of the same text are not specifically aligned. This lets us choose alignment="1", and the 7-bit packed stuff can then have syntax in it, have regex's that it must match, etc. but if alignment="implicit", then the normal, less error prone behavior of skipping to a byte-boundary would be in force.
...mikeb
On Mon, Nov 26, 2012 at 10:10 PM, Mike Beckerle <mbeckerle.dfdl@gmail.com>wrote:
I reviewed this.
2.108 has Change: Format annotations.... and also Remove: Format Annotations. Should just have Change.
3.13 I think we missed a couple places where the previous design where we had replacement control is still leaking into the text.
Phrase "Any character that is skipped counts as 0." should be dropped. We don't skip anymore.
Concerning: "In the following, the match is against data where any character replacement has already taken place." The first sub-bullet about lengthKind pattern is incorrect. For lengthKind pattern I believe any decode error should cause the match to end, i.e., a pattern that matches digits only will match a string of digts followed by binary data that causes a decode error. Similarly, when matching literal nils, (character or literal value), any decode error should cause the match to fail.
On Fri, Nov 23, 2012 at 12:41 PM, Steve Hanson <smh@uk.ibm.com> wrote:
A few corrections made and added errata from Nov 20th call. Please review for next call. Also now on Redmine.
Regards
Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/> IBM SWG, Hursley, UK* **smh@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 23/11/2012 17:40 -----
From: Steve Hanson/UK/IBM To: dfdl-wg@ogf.org, Date: 20/11/2012 14:23 Subject: First draft of DFDL Errata v011 ------------------------------
Please find attached the first draft of Errata v011. This incorporates all DFDL spec errata raised since v010 (June 22 2012) until the last DFDL WG call (November 13 2012). Change tracking: I accepted all changes from v010 so the changes you see are all due to v011. I would appreciate a review for correctness and omissions. Please note that some of the new errata have been best handled by updating existing related errata, so please read from start.
Regards
Steve Hanson Architect, Data Format Description Language (DFDL) Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/> IBM SWG, Hursley, UK* **smh@uk.ibm.com* <smh@uk.ibm.com> tel:+44-1962-815848 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
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
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
-- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412
-- Mike Beckerle | OGF DFDL WG Co-Chair Tel: 781-330-0412
-- Mike Beckerle | OGF DFDL WG Co-Chair | Tresys Technologies Tel: 781-330-0412