- dfdl-wg - lists.ogf.org

Can I specify a terminator for the last element in a sequence?
by Garriss Jr., James P. 24 Jun '13

24 Jun '13

I have a repeating element, one that can occur 1 to unbounded times. The elements are separated by a prefixed separator, like so: <xsd:sequence dfdl:separator="some-separator-here" dfdl:separatorSuppressionPolicy="anyEmpty" dfdl:separatorPosition="prefix"> <xsd:element name="BodyPart" dfdl:lengthKind="delimited" minOccurs="1" maxOccurs="unbounded" type="xsd:string" dfdl:occursCountKind="implicit"/> </xsd:sequence> The last element (and only the last element) has a terminator. Is there a way in DFDL to specify that final terminator?

2 1

Re: [DFDL-WG] Can DFDL parse TLV data?
by Andre Merzky 21 Jun '13

21 Jun '13

Hello, I forwarded your mail to the DFDL-WG mailing list -- they will be able to give a qualified answer. Best regards, Andre. On Fri, Jun 21, 2013 at 10:59 AM, Xin TZ Zhang <xzhangbj(a)cn.ibm.com> wrote: > Dear OFGer: > Can DFDL parse TLV data? TLV(tag-length-value) data is binary, and variable > length... > (sorry for my poor English) > Best Regards zx. -- Nothing is really difficult.

2 1

How to specify type/subtype combos?
by Garriss Jr., James P. 21 Jun '13

21 Jun '13

Content types come in pairs. So while the type can be "text" and the subtype can be "pdf", the complete content type cannot be "text/pdf". It can, however, be "text/html" or "application/pdf". So in my DFDL it's not sufficient to specify enumerated lists for types and subtypes (as I have done below), I must also specify which types are allowed to go with which subtypes. How would I do that, given this complexType? TIA! <xsd:complexType name="MimeTypeType"> <xsd:sequence dfdl:separator="/"> <xsd:element name="Type" dfdl:initiator=""> <xsd:annotation> <xsd:appinfo source="http://www.ogf.org/dfdl/dfdl-1.0/"> <dfdl:assert test="{ dfdl:checkConstraints(.) }" message="The type must match one of the values on the enumerated list."/> </xsd:appinfo> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="([a|A][p|P][p|P][l|L][i|I][c|C][a|A][t|T][i|I][o|O][n|N])| ([m|M][u|U][l|L][t|T][i|I][p|P][a|A][r|R][t|T])| ([m|M][e|E][s|S][s|S][a|A][g|G][e|E])| ([t|T][e|E][x|X][t|T])" /> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="Subtype" dfdl:terminator=""> <xsd:annotation> <xsd:appinfo source="http://www.ogf.org/dfdl/dfdl-1.0/"> <dfdl:assert test="{ dfdl:checkConstraints(.) }" message="The subtype must match one of the values on the enumerated list."/> </xsd:appinfo> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:pattern value="([p|P][d|D][f|F])| ([a|A][l|L][t|T][e|E][r|R][n|N][a|A][t|T][i|I][v|V][e|E])| ([m|M][i|I][x|X][e|E][d|D])| ([r|R][f|F][c|C]822)| ([p|P][l|L][a|A][i|I][n|N])| ([h|H][t|T][m|M][l|L])" /> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:sequence> </xsd:complexType>

4 4

How to ignore case and validate an element with an enumerated list
by Garriss Jr., James P. 20 Jun '13

20 Jun '13

Mike came up with a solid solution to the problem I posted previously. While not quite as elegant as adding the "dfdl:ignoreElementCase=yes" property that I would prefer, it's good enough. Thanks, Mike! Here's the relevant parts: <xsd:complexType name="MimeTypeType"> <xsd:sequence> <xsd:sequence dfdl:hiddenGroupRef="MixedCaseMimeTypeGroup"/>  <xsd:element name="Type" dfdl:inputValueCalc="{ fn:lower-case(../MixedCaseType) }"> <xsd:annotation> <xsd:appinfo source="http://www.ogf.org/dfdl/dfdl-1.0/"> <dfdl:assert test="{ dfdl:checkConstraints(.) }" message="The type must match one of the values on the enumerated list."/> </xsd:appinfo> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="application"/> <xsd:enumeration value="multipart"/> <xsd:enumeration value="message"/> <xsd:enumeration value="text"/> </xsd:restriction> </xsd:simpleType> </xsd:element> <xsd:element name="Subtype" dfdl:inputValueCalc="{ fn:lower-case(../MixedCaseSubtype) }"> <xsd:annotation> <xsd:appinfo source="http://www.ogf.org/dfdl/dfdl-1.0/"> <dfdl:assert test="{ dfdl:checkConstraints(.) }" message="The subtype must match one of the values on the enumerated list."/> </xsd:appinfo> </xsd:annotation> <xsd:simpleType> <xsd:restriction base="xsd:string"> <xsd:enumeration value="pdf"/> <xsd:enumeration value="ms-tnef"/>  <xsd:enumeration value="alternative"/> <xsd:enumeration value="mixed"/> <xsd:enumeration value="rfc822"/> <xsd:enumeration value="plain"/> <xsd:enumeration value="html"/> </xsd:restriction> </xsd:simpleType> </xsd:element> </xsd:sequence> </xsd:complexType>  <xsd:group name="MixedCaseMimeTypeGroup"> <xsd:sequence dfdl:separator="/"> <xsd:element name="MixedCaseType" type="xsd:string"/> <xsd:element name="MixedCaseSubtype" type="xsd:string"/> </xsd:sequence> </xsd:group>

2 1

proposal: functions to allow reasonable syntax for hex constants in DFDL expression language
by Mike Beckerle 20 Jun '13

20 Jun '13

Rationale: in writing DFDL schemas for binary data formats, there is a strong need to express binary data constants in hexadecimal. Proposed new functions: dfdl:hByte dfdl:hUByte dfdl:hShort dfdl:hUShort dfdl:hInt dfdl:hUInt dfdl:hLong dfdl:hULong The prefix 'h' is a reminder that the function converts from hexadecimal. The prefix 'U' on the name denotes that the function creates an unsigned type result. Normally one might like to write this out fully, but in this case brevity is helpful given the expected usage of these functions to construct literal constants in DFDL expressions. All the functions take a single string argument. The string must begin with "0x" and contain at least one hex digit after that. The string must contain only hexadecimal digits, that is, the characters 0-9a-zA-Z. It is a schema definition error otherwise. The hex digits represent a big endian twos complement representation of a binary number. Each function has a limit on the number of hex digits, with no more digits than 2, 4, 8, or 16 for the byte, short, int, and long versions. That is to say for dfdl:byte and dfdl:uByte, there can be at most 2 hex digits. For dfdl:short and dfdl:uShort, there can be at most 4 hex digits, and so on. It is a schema definition error if more digits are encountered than are suitable for the type being created. Examples: dfdl:hUInt("0xa1b2c3d4") is the value 2712847316. Note that in the first byte 'a1' the most significant bit is set, but since this is an unsigned type, this is not interpreted as a sign bit. dfdl:hInt("0xFFFFFFFF") is the int value -1. The sign bit indicates that the number is negative, and this twos complement value represents -1. dfdl:hUByte("0xFF") is the unsigned byte value 255 dfdl:hByte("0xff") is the byte value -1. dfdl:hByte("0x7F") is the byte value 127 dfdl:hByte("0x80") is the byte value -128 dfdl:hUByte("0x80") is the unsigned byte value 128 dfdl:hByte("0x0A3") is a schema definition error as the leading zero is not allowed because at most 2 digits are allowed for byte types. dfdl:hShort("0x0A3") is short value 208. Leading zero causes no issue here because up to 4 digits are allowed. Example of usage in expressions: <xs:element name="magic_number" type="ex:uint32" dfdl:byteOrder="bigEndian"> <xs:annotation> <xs:appinfo source="http://www.ogf.org/dfdl/dfdl-1.0/"> <dfdl:setVariable ref="ex:bOrd"> { if (xs:unsignedInt(.) eq *dfdl:hUInt('0xa1b2c3d4')*) then 'bigEndian' else if (xs:unsignedInt(.) eq *dfdl:hUInt('0xd4c3b2a1')*) then 'littleEndian' else fn:error(ex:magic_number, "Magic number was not 0xA1B2C3D4 (for bigEndian) or 0xD4C3B2A1 (for littleEndian).") } </dfdl:setVariable> </xs:appinfo> </xs:annotation> </xs:element> -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com

3 2

how to do mix of case sensitive and insensitive delimiters
by Mike Beckerle 20 Jun '13

20 Jun '13

I have a wierd case where the initiator wants to be case insensitive matching, but the terminator wants to be case sensitive. The only way I can think of dealing with this is to use the initiator, but handle the length via lengthKind='pattern' to grab the value, doing lookahead so it will stop before the terminator. Then an empty sequence with a case sensitive terminator to pick off that part of the data stream. -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com

4 6

Cancelled: OGF DFDL WG Call
by Steve Hanson 20 Jun '13

20 Jun '13

Steve unavailable

1 0

How do I ignore the case of my initiator and my elements?
by Garriss Jr., James P. 20 Jun '13

20 Jun '13

Issue #1 Email header names have a set value, but in practice SMTP servers do what they want. So this is the required header name for content type: Content-Type: <some value> But variations exist, such as this: Content-type: <some value> Rather than trying to guess every possible combination, I think it would be good to simply ignore the case of the header name. (I have modeled header names as initiators.) Issue #2 The spec says that the value of the content type is case insensitive, so all the following possibilities (and more) are allowed: Content-Type: text/html Content-Type: TEXT/HTML Content-Type: Text/Html Content-Type: tExT/hTmL So obviously I need to be able to ignore the case of the header's value. (I have modeled the type (e.g., text) and the subtype (e.g., html) as elements. And as there's obviously a limited set of allowed for each, I've constrained these with an enumerated list.) I have attached a simplified version of the schema I'm using for the content header. How would I modify it in order to ignore the case of the header name and the header value? TIA!

2 1

clarification needed: Ignore case
by Mike Beckerle 20 Jun '13

20 Jun '13

The ignoreCase property description says this: Whether mixed case data is accepted when matching delimiters and data values on input. This affects the behavior of matching for these properties: initiator, terminator, separator, nilValue, textStandardExponentRep, textStandardInfinityRep, textStandardNaNRep, textStandardZeroRep, textBooleanTrue, textBooleanFalse, Ignoring that dangling comma at the end, the question is about what this leaves out, and making sure this is intentional. 1. If an element of type string has the XSD attribute fixed="...." with some value, is that comparison of the fixed value to the data content guided by dfdl:ignoreCase? 2. If an element of simple type string has enumerations, are the comparisons of the enum values to what is found in the data guided by dfdl:ignoreCase? My thought is No and No, as these are purely XSD issues, not DFDL related, so we want our behavior to be exactly the same as XSD here. The XSD/XML world is simply a very case-sensitive one. This page (http://www.ibm.com/developerworks/library/x-case/) is about a user asking how to do case-insensitive enum comparisons in XSD. The hack workaround is changing to use a pattern/regex match. I.e., instead of case insensitive "red" you get a pattern match of "[r|R][e|E][d|D]" which is blechy, but effective. -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com

3 2

clarification on when escape characters are needed
by Mike Beckerle 19 Jun '13

19 Jun '13

Suppose I have a sequence. It has an infix separator which is "=". <sequence dfdl:separator="=" dfdl:separatorPosition="infix"> <element name="a" type="xs:string"/> <element name="b" type="xs:string"/> </sequence> Now, consider this data: password=f82+=7&%q I want <a>password</a> <b>f82+=7&%q</b> Notice how the b element contains an '=' which was not escaped in any way in the sequence. Element b is statically known to be last, the separator is infix; hence, things are unambiguous even if there is no escaping. However, there is an alternative interpretation, which is that the above data should fail, because it produces <a>password</a><b>f82+</b> but then does not find the expected stuff next. Rather it finds the '=7&%q' data. In other words, the sequence separator divides the sequence content into 3 content regions, but there aren't 3 things to consume those, so it is a processing error. Which is correct? -- Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com

4 10