- dfdl-wg - lists.ogf.org

Fw: Action 258 - data where inactive escape character is to be retained
by Steve Hanson 28 Aug '14

28 Aug '14

Strawman proposal for action 258. 258 Consider allowing more flexible escapeCharacter schemes (Mike) 6/5: Motivated by example of an escape character which is active when in front of an in-scope delimiter, but not when in front of another character. 20/5: Can't model Mike's example with current facilities, but Mike's example is a generalisation of a particular MITRE example. Do we really need this? Jonathan to follow up. 3/6: Closed. Jonathan has provided the background to the MITRE example which was really about initiators and terminators. The generalised use case is perhaps speculative, so it was agreed not to change the DFDL spec to handle this unless a concrete use case emerges. 17/6: Re-opened. vCard 3.0 (http://tools.ietf.org/html/rfc2426) is an example of a format that exhibits the need for this. Need a proposal to handle this case, and which fits in with the existing extraEscapedCharacters and escapeEscapeCharacter property. Noted that using lengthKind 'pattern' is sometimes a way of working round this kind of thing. ... 15/7: No progress 22/7: Steve has started to write up a proposal. New property dfdl:applyEscapeCharacter added. The description of dfdl:escapeKind is updated. No changes to dfdl:generateEscapeBlock but I've added it below by way of comparison. Property Name Description escapeKind Enum Valid values 'escapeCharacter', 'escapeBlock' The type of escape mechanism defined in the escape scheme When 'escapeCharacter': On unparsing a single character of the data is escaped by adding a dfdl:escapeCharacter or dfdl:escapeEscapeCharacter immediately before it. The characters to escape are determined by property dfdl:applyEscapeCharacter. On parsing any in-scope terminating delimiter encountered in the data is not interpreted as such when it is immediately preceded by the dfdl:escapeCharacter (when not itself preceded by the dfdl:escapeEscapeCharacter). Occurrences of the dfdl:escapeCharacter and dfdl:escapeEscapeCharacter are removed from the data as determined by property dfdl:applyEscapeCharacter unless the dfdl:escapeCharacter is preceded by the dfdl:escapeEscapeCharacter, or the dfdl:escapeEscapeCharacter does not precede the dfdl:escapeCharacter, respectively. When 'escapeBlock': On unparsing the entire data are escaped by adding dfdl:escapeBlockStart to the beginning and dfdl:escapeBlockEnd to the end of the data. The data is either always escaped or escaped when needed as specified by dfdl:generateEscapeBlock. If the data is escaped and contains the dfdl:escapeBlockEnd then first character of each appearance of the dfdl:escapeBlockEnd is escaped by the dfdl:escapeEscapeCharacter. On parsing the dfdl:escapeBlockStart string must be the first characters in the (trimmed) data in order to activate the escape scheme. The dfdl:escapeBlockStart string is removed from the beginning of the data. Until a matching dfdl:escapeBlockEnd string (that is, one not preceded by the dfdl:escapeEscapeCharacter) is found in the data, any in-scope terminating delimiter encountered in the data is not interpreted as such, and any dfdl:escapeEscapeCharacters are removed when they precede an dfdl:escapeBlockEnd string. The matching dfdl:escapeBlockEnd string is removed from the data.. The matching dfdl:escapeBlockEnd does not have to be the last characters in the (trimmed) data in order to de-activate the escape scheme. A dfdl:escapeBlockStart occurring anywhere in the data other than the first characters has no significance. Annotation: dfdl:escapeScheme applyEscapeCharacter Enum Valid values 'whenNeeded', 'delimiters' Controls when escape characters are removed during parsing, and output during unparsing, when dfdl:escapeKind is 'escapeCharacter'. When 'whenNeeded': During unparsing the following are escaped as described in dfdl:escapeKind when they are in the data. · Any in-scope terminating delimiter by escaping its first character. · dfdl:escapeCharacter (escaped by dfdl:escapeEscapeCharacter) · any dfdl:extraEscapedCharacters During parsing, occurrences of dfdl:escapeCharacter and dfdl:escapeEscapeCharacter are interpreted and removed from the data as described in dfdl:escapeKind. When 'delimiters': During unparsing the following are escaped as described in dfdl:escapeKind when they are in the data. · Any in-scope terminating delimiter by escaping its first character. · dfdl:escapeCharacter (escaped by dfdl:escapeEscapeCharacter) During parsing, occurrences of dfdl:escapeCharacter and dfdl:escapeEscapeCharacter are interpreted and removed from the data as described in dfdl:escapeKind, except that dfdl:escapeCharacter is only removed when it immediately precedes an in-scope terminating delimiter. Annotation: dfdl:escapeScheme generateEscapeBlock Enum Valid values 'always', 'whenNeeded' Controls when escaping is used on unparsing when dfdl:escapeKind is 'escapeBlock'. If 'always' then escaping always occurs as described in dfdl:escapeKind. If 'whenNeeded' then escaping occurs as described in dfdl:escapeKind when the data contains any of the following: · any in-scope terminating delimiter · dfdl:escapeBlockStart at the start of the data · any dfdl:extraEscapedCharacters Annotation: dfdl:escapeScheme Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 22/07/2014 15:10 ----- From: Steve Hanson/UK/IBM To: "Cranford, Jonathan W." <jcranford(a)mitre.org>, Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org> Date: 13/06/2014 17:28 Subject: Re: [DFDL-WG] data where inactive escape character is to be retained I think I have come across a concrete example of this. It's from a standard called vCard 3.0 (RFC 2426 - http://tools.ietf.org/html/rfc2426) A backslash is used to a) escape itself; b) escape in-scope delimiters; c) indicate an embedded linefeed. The backslash would need removing for a) and b) but not for c). ESCAPED-CHAR = "\\" / "\;" / "\," / "\n" / "\N") ; \\ encodes \, \n or \N encodes newline ; \; encodes ;, \, encodes , Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Steve Hanson/UK/IBM To: "Cranford, Jonathan W." <jcranford(a)mitre.org>, Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org>, dfdl-wg-bounces(a)ogf.org, Mike Beckerle <mbeckerle.dfdl(a)gmail.com> Date: 04/06/2014 08:53 Subject: Re: [DFDL-WG] data where inactive escape character is to be retained WG call 3rd June: The generalised use case is perhaps speculative, so it was agreed not to change the DFDL spec to handle this unless a concrete use case emerges. Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: "Cranford, Jonathan W." <jcranford(a)mitre.org> To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com>, "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org>, Date: 20/05/2014 18:11 Subject: Re: [DFDL-WG] data where inactive escape character is to be retained Sent by: dfdl-wg-bounces(a)ogf.org All, I’ll chime in with an observation and few more details on how Roger Costello got around a similar problem. Observation An escape block allows the escapeBlockEnd to be escaped with the escapeEscapeCharacter, while allowing the escapeEscapeCharacter itself to appear in the data without any special semantics as long as it is NOT followed by escapeBlockEnd. (From section 13.2.1 of the spec: “On parsing the dfdl:escapeBlockStart is removed from the beginning of the data and dfdl:escapeBlockEnd is removed from end of the data and any dfdl:escapeEscapeCharacters are removed when they precede a dfdl:escapeBlockEnd.”) This is really similar to the problem that Mike posed to the group below, where an escape character is sometimes an escape character but sometimes isn’t. While an escape block might not be suitable in all circumstances, the original problem that sparked Mike’s post was amenable to using an escape block, and that is how Roger Costello got around the problem. Some more details Roger Costello was using a quotation mark (“) as the initiator and terminator for quoted values in a data format. In this format, quotation marks can be escaped with a backslash (\); however, within a quoted string, the data could have a backslash as a normal data character (e.g. \n, representing two characters, not a single newline character). Roger posed his challenge to the Daffodil team, and then Mike created the example below to demonstrate the problem to the DFDL WG. In contrast to Mike’s example, Roger was having the problem with initiators and terminators, not a separator. At the time, we thought that that an escape block couldn’t be applied to the data format in question, so Mike may have altered the problem in order to prevent an escape block from clouding the issue as posed to the WG. It turns out, after more analysis, that an escape block could be used, and that solved the problem: escapeBlockStart=”"” escapeBlockEnd=”"” escapeEscapeCharacter=”\” Closing Observations In general, DFDL supports two different escape schemes with different behavior for the escape character. * When escapeKind=”escapeCharacter”, the escape character is always an escape character. * When escapeKind=”escapeBlock”, the escape character (escapeEscapeCharacter) is only an escape character in front of escapeBlockEnd. In this case, we were able to use an escape block to model the data format. While there may be a data format that has a character that is sometimes an escape character and sometimes isn’t, without a real world example, I echo Mike’s hesitance to add this feature to DFDL. HTH, Jonathan Cranford From: dfdl-wg-bounces(a)ogf.org [mailto:dfdl-wg-bounces@ogf.org] On Behalf Of Mike Beckerle Sent: Friday, May 02, 2014 2:47 PM To: dfdl-wg(a)ogf.org Subject: [DFDL-WG] data where inactive escape character is to be retained We have data that has ; as separator and has fields that look like this: abcd \; efgh That's a single field. The backslash escapes the ; so that the data is abcd ; efgh. This same data set also has abcd \n efgh Here the backslash precedes an ordinary non-delimiter. The data is supposed to be abcd \n efgh. That is, this data set requires the backslash to be retained in the data when it is not preceding the start of a delimiter. Am I missing something or is it impossible to model this? It would seem there needs to be a flag to indicate whether the escape characters that don't actually escape a delimiter are to be retained or not. 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 -- dfdl-wg mailing list dfdl-wg(a)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 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

1 0

OGF DFDL WG Call Minutes 2014-08-26
by Steve Hanson 26 Aug '14

26 Aug '14

Please find minutes from the above call at http://redmine.ogf.org/dmsf_files/13322?download= Please review spec draft r22 on Redmine when published. Email any comments to dfdl-wg(a)ogf.org. Note next call is 26th Aug. Regards Steve Hanson Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

OGF DFDL WG Call Agenda 2014-08-26
by Steve Hanson 22 Aug '14

22 Aug '14

Please find agenda for call on Redmine at http://redmine.ogf.org/dmsf_files/13322?download= Please review spec draft r21 on Redmine. Email any comments to dfdl-wg(a)ogf.org. Regards Steve Hanson Architect, IBM Data Format Description Language (DFDL) Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

posted draft r21 and bit-order-features 3.1
by Mike Beckerle 22 Aug '14

22 Aug '14

I've posted revised draft of the spec r21 (has changes to DFDL Standard Character sets per call today) I also made corrections to dfdl:byteOrder - added missing binary booleans as one of the things byteOrder applies to, and removed sequence, choice, group from things that can carry the byteOrder property. Having done these fixes I realized this probably requires an erratum actually. r21 is at http://redmine.ogf.org/dmsf_files/13318 I've posted bit-order-features 3.1. This is http://redmine.ogf.org/dmsf_files/13317 Language revised to make bitOrder more primitive than byteOrder - applies to all grammar regions. Also added implicit-aligning to byte boundary on a bit-order change. 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>

2 3

"all whitespace as zero"
by Mike Beckerle 11 Aug '14

11 Aug '14

> > If 'lax' and dfdl:textNumberRep is 'standard' then grouping > separators can be omitted, decimal separator can be either '.' > or ',' (as long as this is unambiguous), leading positive sign > can be omitted, all whitespace is treated as zero, and leading > and trailing whitespace is ignored. Also the exponent is also > optional and assumed to be '1' if not supplied The part that seems odd: "all whitespace is treated as zero" So according to this, if the data is: " 9 9 " then with textNumberCheckPolicy="lax", the leading/trailing whitespace is trimmed and the middle whitespace is converted to zero, so this is equivalent to "909". This feels like a spec bug to me, but I wanted to have others confirm this. Note that I don't think this behavior is consistent with what icu4j does. It simply ignores the middle space and converts the data to "99". It's possible we're not setting an ICU4J flag, though, I don't see an obvious ICU4J flag that would control this. 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>

1 0

Fw: Action 261
by Steve Hanson 06 Aug '14

06 Aug '14

In the spec as it stands, occursCountKind 'expression' has behaviour like occursCountKind 'fixed' when parsing (ie, there is a count that is fixed before the occurrences are parsed), but is also stated to have behaviour like occursCountKind 'parsed' when unparsing (ie, there is no count that is fixed before occurrences are unparsed). In terms of expected separators, it behaves like 'never' when parsing, but like 'anyEmpty' when unparsing. This leads to undesirable asymmetric behaviour, such as this example. Data stream is 5,A,B,,D,E. To preserve indexes in the infoset after parsing, I make the array element nillable with ES as nil value. But on unparsing I will get 5,A,B,D,E because the 'anyEmpty' behaviour has suppressed the output of the separator for the zero-length nil value. Not only will modellers find this behaviour odd, it breaks dfdl:outputValueCalc on the count element if fn:count() is used. (Same happens if not nillable but minOccurs > 2 so empty string ends up in the infoset). The proposal is that 'expression' behaves like 'never' on unparsing, the count being taken as the number of items in the augmented infoset. That way the application or outputValueCalc can be certain that no separators will be suppressed, and outputValueCalc will work. It was proposed further down this email thread that the expression is evaluated at the start of unparsing the element and used to obtain the count. There are scenarios where that causes problems though, hence the above is preferred. However, to ensure that the output data stream can be re-parsed, it is proposed that the expression is evaluated at the end of the unparsing of the element (and any elements with expressions dependent on it), and if it fails to match the number that was output, it is a processing error. Similarly for lengthKind 'explicit' where length is an expression. The element continues to be considered variable length on unparsing as the spec says today, but the expression is evaluated at the end of the unparsing of the element, and if it fails to match the length that was output, it is a processing error. It would be great to do the analogous thing for lengthKind 'pattern' but it is not always possible as some patterns look ahead beyond the element content in order to match. So it could be done for some patterns but not all. Implementation-dependent? Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 06/08/2014 13:08 ----- From: Steve Hanson/UK/IBM To: dfdl-wg(a)ogf.org, Date: 25/06/2014 11:33 Subject: Fw: [DFDL-WG] Action 261 261 Implied separatorSuppressionPolicy for occursCountKind 'expression' (All) 10/6: Spec says it is 'never' (positional sequence) but you have to parse to identify the position, so isn't that non-positional? 17/6: Some other issues noted around 'expression' as per email thread. IBM have discussed this internally and will submit a proposal. As was noted in the email for Action 260, if it is decided that the meaning of "Each occurrence in the sequence can be identified by its position in the data" is more strictly that an observer of the raw data can identify an occurrence of an element in the sequence solely by counting separators then that would appear to make dfdl:occursCountKind 'expression' more like 'parsed', and not eligible to be in a Positional sequence. But if the meaning is a parser does not have to speculate to identify an occurrence of an element in the sequence then it can be in a Positional sequence. While discussing the nature of 'expression' it was noted that it is very easy for a DFDL user to create a data stream from an infoset and for that data stream to be un-parse-able. If dfdl:outputValueCalc is not used, then the element(s) in the infoset must be correctly set manually to match the number of occurrences. The same observation applies to dfdl:lengthKind 'explicit' where dfdl:length is an expression. To address this, IBM proposes the following changes to the DFDL specification for occursCountKind 'expression' when unparsing: When all occurrences have been obtained from the infoset (and defaulting applied if needed), the occursCount expression is evaluated If any element that is referenced by the expression has dfdl:outputValueCalc, then that expression is (re-)evaluated as part of the above; given that the number of occurrences is now known, the outputValueCalc expression should now evaluate successfully If the result of the occursCount does not match the number of occurrences it is a processing error This ensures the integrity of the data stream (the non-outputValueCalc use case), while still allowing the infoset to dictate the count (the outputValueCalc use case). Similarly, IBM proposes the following changes to the DFDL specification for lengthKind 'explicit', where length is an expression, when unparsing: When an element has been obtained from the infoset (and defaulting applied if needed) and unparsed but before padding is applied, the expression is evaluated to give a length. If any element that is referenced by the expression has dfdl:outputValueCalc, then that expression is (re-)evaluated; given that the unpadded length is now known, the outputValueCalc expression should now evaluate successfully Now that we have a length, the unparser behaviour is the same as if the length was obtained from a fixed dfdl:length value. (That is, truncation, padding, filling or error depending on other property settings). This ensures the integrity of the data stream (the non-outputValueCalc use case), while still allowing the infoset to dictate the length (the outputValueCalc use case). Note that it means the 'awkward' behaviour whereby lengthKind 'explicit' (expression) is a specified length when parsing but variable length when unparsing is avoided - it is now always specified length. IBM believes that none of the above should impose additional burden on implementers, as no brand new behaviour is being added. Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 25/06/2014 10:24 ----- From: Tim Kimber/UK/IBM To: Steve Hanson/UK/IBM@IBMGB, Alex Wood1/UK/IBM@IBMGB, Andrew Edwards/UK/IBM@IBMGB, Mark Frost/UK/IBM@IBMGB, Date: 16/06/2014 22:08 Subject: Re: [DFDL-WG] Action 261 I think this needs to be discussed before the meeting tomorrow. I wanted to avoid turning this thread into a monster - but I don't think it's possible to discuss without the context so I've continued the thread as before with <tk> tags. I'm clear in my own mind that I understand the issues now. We should give priority to the separatorSuppressionPolicy question because the current rules are close to being unimplementable. The occursCountKind and lengthKind questions are important but are at least implementable as they stand. regards, Tim Kimber, IBM Integration Bus Development (Industry Packs) Hursley, UK Internet: kimbert(a)uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Steve Hanson/UK/IBM To: Tim Kimber/UK/IBM@IBMGB, Cc: dfdl-wg(a)ogf.org, dfdl-wg-bounces(a)ogf.org Date: 11/06/2014 16:12 Subject: Re: [DFDL-WG] Action 261 Replies in <smh> tags Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Tim Kimber/UK/IBM@IBMGB To: dfdl-wg(a)ogf.org, Date: 11/06/2014 13:58 Subject: Re: [DFDL-WG] Action 261 Sent by: dfdl-wg-bounces(a)ogf.org comments in <tk>tags regards, Tim Kimber, IBM Integration Bus Development (Industry Packs) Hursley, UK Internet: kimbert(a)uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Steve Hanson/UK/IBM To: Tim Kimber/UK/IBM@IBMGB, Cc: dfdl-wg(a)ogf.org, dfdl-wg-bounces(a)ogf.org Date: 11/06/2014 10:47 Subject: Re: [DFDL-WG] Action 261 Some thoughts on this... I agree that the definition of positional sequence in the spec needs tightening as it is ambiguous as it stands and could be interpreted as a) or b). If we adopted b) then that would appear to allow 'expression' to appear in a positional sequence, but wouldn't it also allow 'stopValue'? <tk>Yes - according to definition b) stopValue would be allowable in a positional sequence. We could still disallow it if we do not believe there is any benefit in allowing it. I don't believe it introduces any particular complexities for an implementer.</tk> occursCountKind 'expression' is analogous to lengthKind 'explicit' with an expression and to lengthKind 'prefixed'. Both these lengthKinds are classified as 'specified length' when parsing but 'variable length' when unparsing. We are observing that occursCountKind 'expression' is like 'fixed' when parsing but not quite so like 'fixed' when unparsing - which is why section 16 groups 'expression' with 'parsed' for unparsing. <tk>Yes - we took a decision that the unparser should ignore the expression in lengthKind/occursCountKind, and just output whatever data happens to be in the info set. I'm not sure that it saves a lot of effort in the implementation and it certainly is not easy to justify as a consistent behaviour. For me, the unparser should treat lengthKind='explicit' the same way whether the value is static or calculated. And the unparser should treat occursCountKind='expression' the same way as occursCountKind='fixed'. </tk> When unparsing occursCountKind 'expression' you don't always have the calculated array length N. If the infoset was derived from XML, there is likely no 'count' element, just a bunch of elements with the same name that make up the 'array'. DFDL gives you the choice whether to a) manually set the count element, or b) have the unparser set it automatically via outputValueCalc. In the former case, you can create a document that can not be parsed; the unparser could check the 'count' element matches the infoset, but that would involve reverse engineering an arbitrarily complex expression and is why the specification does not say that. <tk>It would involve evaluating the expression. In most cases, that will not require any lookahead because the Length/Count field will precede the array or element. Not sure where the reverse engineering comes in?</tk> <smh>I see what you are saying. Just evaluate the expression and see what it gives for N. That handles case a) but not b) where I explicitly want the unparser to set the count via outputValueCalc - which is presumably referring to the number of elements in the array, which is not known. For case b) N has to be the number in the infoset. Given that we have to support case b) the unparser can not treat occursCountKind 'expression' exactly the same as 'fixed' when unparsing.</smh> <smh>Similarly with lengthKind 'explicit' with an expression. For the equivalent to case a) the length is known which makes the length fixed, but for the equivalent of case b) with outputValueCalc the length is not known so it is variable. When this was discussed in the past, it was decided not to bifurcate the expression scenario. Hence the spec is the way it is. </smh> <tk> That helps. So your belief is that case a) is workable but case b) is not because the number of elements in the array is not known. I don't think that holds up under scrutiny. In case b), the outputValueCalc expression cannot be evaluated until all of the array has been received. So if the info set is received as an event stream then the unparser must wait until the array completes before evaluating the expression. Note that the 'count' ( or 'length' ) field cannot be serialized until its value is known. But the array ( or variable-length field ) comes *after* the count/length field. By the time unparsing of the array/field begins, the value *is* known. The implementation of case a) is actually less straightforward. If the field is an array length and the value is less than the number of items in the info set then I think the unparser must issue an error. If greater then the unparser could output default values ( if available ) or delimiters ( if the parent sequence is a positional sequence with a delimiter ) or else an error if neither are possible. More simply, the unparser could simply insist that the value must correctly describe the data, and I think that's a reasonable rule. Similarly for the length. If the length of the *unparsed* value is greater than the value in the info set then the unparser should issue an error. If it is shorter and the field is simple then pad characters could be added. But again, I think real-world usage of length counts suggests that padding is unlikely to be wanted, and the unparser should simply insist on the length field being correct. </tk> Here's a real example of such an expression (albeit with lengthKind 'explicit' but the principle is the same): dfdl:length="{xs:nonNegativeInteger(fn:floor((../Length + 1) div 2))}" Alex brought up the case where the expression evaluates to 0. In a positional sequence, would you still expect a delimiter for this case? <tk>Yes, unless it is in the trailing optional region of the group and SSP='trailingEmpty'. In a positional sequence, every delimiter must be present until suppression begins ( if allowed )</tk> If 'yes' then the resultant zero length string must be treated as the 'absent representation' and ignored. If 'no' then is the sequence still positional? <tk>I don't understand the point. Why would it not be the 'empty representation'? Why must it be 'ignored' if it does happen to be the 'absent representation'? What does 'ignored' mean?</tk> <smh>The point is that the parser has been told there are 0 occurrences. So it would be odd if the infoset ended up containing an occurrence, which can happen if the normal nil/empty rules are followed. (Eg, nilValue=%ES;). <tk> If the occursCount expression evaluates to zero then the parser will not attempt to parse even one occurrence of the array. That's the natural meaning of 'zero occurrences'. So nothing would go into the info set apart from the 'count' field. This is entirely consistent with my definition b) of 'positional' ( the identity of every delimited field is known before parsing of the field begins ). </tk> Hence the 0 occurrence case must treat it as absent which means nothing is added to the infoset. Take the ISO8583 bitmap use case - if the bit is 0 we must not try to parse anything at all for that element - it is totally absent.</smh> <tk>Yes - that's exactly my point. The fact that there is ( or could be ) a delimiter after the 'count' field is irrelevant.</tk> Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Tim Kimber/UK/IBM@IBMGB To: dfdl-wg(a)ogf.org, Date: 10/06/2014 21:22 Subject: [DFDL-WG] Action 261 Sent by: dfdl-wg-bounces(a)ogf.org Implied separatorSuppressionPolicy for occursCountKind 'expression ' (All) 10/6: Spec says it is 'never' (positional sequence) but you have to parse to identify the position, so isn't that non-positional? I think there are two alternative definitions of 'positional': a) the identity of every delimited field is known before parsing of the sequence group begins b) the identity of every delimited field is known before parsing of the field begins As an implementer, b) is sufficient because it means that the parser never needs to backtrack while parsing the group. a) allows the field identities to be statically known, but that is less important - it does not allow optimised extraction of a particular field as would be the case for a fixed-length group ( the possibility of escaped separators/terminators means that every character will need to be scanned anyway ). It may sound like a small point, but it affects two decisions 1. whether ock='expression' should be allowed within a positional sequence group ( action 261 ) 2. what the behaviour of the unparser should be w.r.t. ock='expression'. My own feeling is that ock='expression' should be treated almost exactly like ock='fixed', except that the calculated array length N is used instead of maxOccurs. - When parsing a positional sequence group it should cause N delimiters to be expected for the array. - When unparsing a positional sequence group it should cause N delimiters to be written. These rules are consistent and straightforward to describe and implement. The current rule ( unparser outputs the occurrences that are in the info set only ) allows the unparser to write a document that cannot be parsed using the same schema. regards, Tim Kimber, ----- Forwarded by Tim Kimber/UK/IBM on 10/06/2014 20:34 ----- From: Steve Hanson/UK/IBM@IBMGB To: dfdl-wg(a)ogf.org, Date: 10/06/2014 17:57 Subject: [DFDL-WG] OGF DFDL WG Call Minutes 2014-06-10 Sent by: dfdl-wg-bounces(a)ogf.org Please find minutes from the above call at http://redmine.ogf.org/dmsf_files/13263?download= Regards Steve Hanson Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 -- dfdl-wg mailing list dfdl-wg(a)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 -- dfdl-wg mailing list dfdl-wg(a)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 -- dfdl-wg mailing list dfdl-wg(a)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 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

1 0

Fw: Action 260
by Steve Hanson 06 Aug '14

06 Aug '14

So my suggestion below to wrap the array in a sequence does not work, it just moves the problem down into the new sequence. After much deliberation, we think that the definitions of Positional sequence and Non-positional sequence should not be viewed as driving the behaviour of a sequence, but simply as the resultant characteristics of a sequence that has certain properties. That leaves modellers free to mix occursCountKinds, as in Tim's example. No need for any new SDE scenarios. Positional sequence - Each occurrence in the sequence can be identified by its position in the data. Typically the components of such a sequence do not have an initiator. In some such sequences, the separators for optional zero-length occurrences may or must be omitted when at the end of the group. In DFDL, a sequence is considered positional if it contains only required elements and/or optional and array elements that have dfdl:occursCountKind 'implicit', 'fixed' or 'expression', and it has dfdl:separatorSuppressionPolicy 'never', 'trailingEmptyStrict' or 'trailingEmpty'. Non-positional sequence - Occurrences in the sequence cannot be identified by their position in the data alone. Often the components of such a sequence have an initiator. Such sequences sometimes allow the separator to be omitted for optional zero-length occurrences anywhere in the sequence. Speculative parsing might need to be employed by to identify each occurrence. In DFDL, a sequence is non-positional if it contains any optional or array elements that have dfdl:occursCountKind 'parsed' or 'stopValue', and/or it has dfdl:separatorSuppressionPolicy 'anyEmpty'. See parallel email for action 261 that ensures 'expression' behaves itself. One behaviour that is missing from the spec. For a sequence with separators, what is expected in the data stream if occursCount = 'fixed' / 'implicit' and maxOccurs = '0', or occursCountKind = 'expression' and occursCount evaluates to 0 ? We believe that no separator should be expected when parsing and none output when unparsing (same behaviour as inputValueCalc). Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 ----- Forwarded by Steve Hanson/UK/IBM on 06/08/2014 12:42 ----- From: Steve Hanson/UK/IBM To: Tim Kimber/UK/IBM@IBMGB, Cc: dfdl-wg(a)ogf.org, dfdl-wg-bounces(a)ogf.org Date: 30/06/2014 10:04 Subject: Re: [DFDL-WG] Action 260 You would wrap the array and it's count in a sequence. Then the 'count+array' is treated as a single entity as far as the parent sequence is concerned. Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848 From: Tim Kimber/UK/IBM@IBMGB To: dfdl-wg(a)ogf.org, Date: 26/06/2014 20:06 Subject: Re: [DFDL-WG] Action 260 Sent by: dfdl-wg-bounces(a)ogf.org Before we settle one way or the other, I would like the following data format to be taken into consideration. chars,5,A,B,C,D,E,integers,1,2,3 chars,3,C,,,integers,2,10,11 I am assuming that the occursCountKind for the arrays is 'expression' and the occursCount refers to the integer field that precedes the array. In order to represent the empty strings on the second line it is essential to specify SSP as 'trailingEmpty' or 'never'. If we disallow the combination of ock='expression' and SSP='trailingEmpty' then how would this format be modelled? regards, Tim Kimber, Technical Lead for IBM Integration Bus Healthcare Pack Hursley, UK Internet: kimbert(a)uk.ibm.com Tel. 01962-816742 Internal tel. 37246742 From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> To: Steve Hanson/UK/IBM@IBMGB, Cc: "dfdl-wg(a)ogf.org" <dfdl-wg(a)ogf.org> Date: 25/06/2014 16:25 Subject: Re: [DFDL-WG] Action 260 Sent by: dfdl-wg-bounces(a)ogf.org I prefer choice (a) for two reasons * It is more restrictive and therefore more conservative (preserving freedom to change in future if needed) * If a user has a positional data format, you don't want them to even have to understand the concept of speculation in order to model their data. So choice (a) allows a simpler description that doesn't need to introduce the notion that the parser might be speculation. 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 On Wed, Jun 25, 2014 at 5:20 AM, Steve Hanson <smh(a)uk.ibm.com> wrote: 260 Positional and non-positional sequences (All) 10/6: Spec defines the above but also allows different occursCountKinds within the same sequence which may have different (implied) separatorSuppressionPolicy, which results in a sequence which is a mixture of both. Should this be allowed? If so what are the rules? Can certain combinations be disallowed? 17/6: IBM have discussed internally and will submit a proposal. In the spec we define Positional Sequence and Non-Positional Sequence: Positional sequence - Each occurrence in the sequence can be identified by its position in the data. Typically the components of such a sequence do not have an initiator. In some such sequences, the separators for optional zero-length occurrences may or must be omitted when at the end of the group. A positional sequence can be modelled by setting dfdl:separatorSuppressionPolicy to 'never', 'trailingEmptyStrict' or 'trailingEmpty'. Non-positional sequence - Occurrences in the sequence cannot be identified by their position in the data alone. Typically the components of such a sequence have an initiator. Such sequences allow the separator to be omitted for optional zero-length occurrences anywhere in the sequence. Speculative parsing is employed by the parser to identify each occurrence. A non-positional sequence can be modelled by setting dfdl:separatorSuppressionPolicy to 'anyEmpty'. The problem is that the setting of dfdl:separatorSuppressionPolicy is only examined for child elements with dfdl:occursCountKind 'implicit'. For other dfdl:occursCountKinds, there is the concept of an 'implied' dfdl:separatorSuppressionPolicy: When dfdl:occursCountKind is 'fixed' then ... the implied behaviour is 'never'. When dfdl:occursCountKind is 'expression' ... the implied behaviour is 'never'. When dfdl:occursCountKind is 'parsed' ... the implied behaviour is 'anyEmpty'. When dfdl:occursCountKind is 'stopValue' ...the implied behaviour is 'anyEmpty'. So if a Positional sequence as defined above contains children with dfdl:occursCountKind 'parsed' or 'stopValue' then surely it is no longer a Positional sequence. A solution to this is to prevent the appearance of certain values of dfdl:occursCountKind within a Positional sequence. However, precisely which values to outlaw is subject to interpretation of the phrase "Each occurrence in the sequence can be identified by its position in the data". Is this intended to mean: a) an observer of the raw data can identify an occurrence of an element in the sequence solely by counting separators => SDE if 'parsed', 'stopValue' or 'expression' ** appeared in a Positional sequence; ** Although 'expression' would appear to be like 'fixed' it actually breaks a) so must be included in the SDE list. or b) a parser does not have to speculate to identify an occurrence of an element in the sequence => SDE only if 'parsed' appeared in a Positional sequence. Note that it is possible to wrap a 'parsed' etc element in a local sequence or another element to avoid an SDE. But this could still be seen as a violation of a) if the separators of both are the same, as the observer can not count the separators. So should the rule be applied recursively, ie, a Positional sequence can not contain a non-Positional sequence unless the separators are different? Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)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 -- dfdl-wg mailing list dfdl-wg(a)ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg -- dfdl-wg mailing list dfdl-wg(a)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 -- dfdl-wg mailing list dfdl-wg(a)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 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

1 0

OGF DFDL WG Call Minutes 2014-08-04
by Steve Hanson 04 Aug '14

04 Aug '14

Please find minutes from the above call at http://redmine.ogf.org/dmsf_files/13316?download= Please review spec draft r21 on Redmine. Email any comments to dfdl-wg(a)ogf.org. Note next call is 26th Aug. Regards Steve Hanson Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Cancelled: DFDL Working Group Call
by Steve Hanson 04 Aug '14

04 Aug '14

Steve on holiday

1 0

Cancelled: DFDL Working Group Call
by Steve Hanson 04 Aug '14

04 Aug '14

Steve on holiday

1 0