December 2017 - dfdl-wg - lists.ogf.org

clarification needed: unparsing and hidden group choices and choices with dfdl:choiceDispatchKey
by Mike Beckerle 13 Dec '19

13 Dec '19

So interesting issue. Comes up as part of our experience implementing the advanced expression language features: hidden groups, and computed elements. We have hidden groups in DFDL. If a xs:choice is inside a hidden group, then by definition, when unparsing, elements corresponding to some branch of the choice are not in the Infoset. DFDL spec clearly states that dfdl:outputValueCalc is not allowed on the head of a choice branch. But elements inside hidden groups must have dfdl:outputValueCalc, or a default value, otherwise there's no way for them to be filled in as part of the augmented infoset. So the only way a choice can be inside a hidden group is if the head of the choice branches have default values. This is not sufficient. I do not think it was our intention to make hidden groups incapable of holding things complex enough to contain a choice. Rather, the point is to be able to hide things that have excess complexity needed only for parsing/unparsing, so that they need not appear in the final Infoset. So if a choice is allowed inside a hidden group, then a mechanism is needed by which when unparsing a choice branch is selected based on values of other parts of the Infoset, and then the elements of that branch are computed and added to the augmented infoset. Note that without hidden groups, this problem never arises, as the Infoset always has to take a position on choice branches by having an unambiguous element in it. There are 3 cases: 1. unparsing an xs:choice where for parsing, each branch has a discriminator, or is resolved by the simple "first successful parse" rule. 2. unparsing an xs:choice with dfdl:choiceDispatchKey 3. unparsing xs:choice with dfdl:initiatedContent='yes' For all cases, I suggest we must remove the restriction on dfdl:outputValueCalc being disallowed on choice branch head. For (1). First branch where the branch can be constructed successfully is added to the augmented infoset. This is a case where an unparse error is non-fatal, and causes a form of unparser backtracking through alternatives. Branches would be attempted in schema order. For (2) I suggest dfdl:unparseChoiceDispatchKey, evaluated at unparse time only. Produces a choice branch key. That choice branch is then constructed, and default values or dfdl:outputValueCalcs are used to fill in values. (BTW: this is the driving use case we have in Daffodil for this issue.) For (3).... I have no specific solution. I think it may not actually be a separate case and has to be treated as (1) or (2). Comments/Discussion?

2 1

Latest OGF DFDL WG Call Minutes
by Steve Hanson 12 Dec '17

12 Dec '17

Please find minutes from the latest call at https://redmine.ogf.org/projects/dfdl-wg/news Regards Steve Hanson IBM Hybrid Integration Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

Agenda for next OGF DFDL WG Call
by Steve Hanson 12 Dec '17

12 Dec '17

Please find agenda for call on Redmine at https://redmine.ogf.org/dmsf_files/13569?download= Regards Steve Hanson IBM Hybrid Integration Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

OGF DFDL Working Group call
by Steve Hanson 12 Dec '17

12 Dec '17

1 0

Fw: OPC-UA DateTime values
by Steve Hanson 12 Dec '17

12 Dec '17

Requirement to allow DFDL to understand Windows FILETIME type as well as Unix time type. Although DFDL allows the epoch to be specified via dfdl:binaryCalendarEpoch, it can only handle seconds or milliseconds. It would need to add a new binaryCalendarRep 'binaryTick' to handle the '100 nanoseconds' units. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 ----- Forwarded by Steve Hanson/UK/IBM on 12/12/2017 09:48 ----- From: Andreas Martens1/UK/IBM To: Steve Hanson/UK/IBM@IBMGB Date: 08/12/2017 17:48 Subject: OPC-UA DateTime values Hi Steve, I'm working on processing OPC-UA DateTime elements, which are specified by: "A 64-bit signed integer representing the number of 100 nanoseconds intervals since 1601-01-01 00:00:00. This is the same as the WIN32 FILETIME type." (From OPC UA Part 3 - Address Space Model 1.03 Specification, available from opcfoundation.org) Now they might have been a bit conservative on the truth, here's Micosoft's specification: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724284(v=vs.85).… Which doesn't mention whether it's signed or not (in fact, it's split in two parts, potentially to maintain compatibility backwards (have thay always used 1601 as their epoch?)) typedef struct _FILETIME { DWORD dwLowDateTime; DWORD dwHighDateTime; } FILETIME, *PFILETIME; actually, DWORD is unsigned, so it's definitely unsigned, so OPC foundation are liars! cheers, Andreas -- Andreas Martens Emerging Technology IBM Research IBM Hursley Park, Winchester, SO21 2JN Phone: +44 (0) 1962 816833 37246833 www.emerging-technology.co.uk 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