March 2018 - 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

Re: [DFDL-WG] Action Item: Versioning mechanism for DFDL v2.0 features/changes
by Mike Beckerle 28 Apr '19

28 Apr '19

So if a schema doesn't use dfdl:format at all, then it doesn't hurt to add <dfdl:format DFDLVersion="2"/> to it at top level in order to express version when DFDL v2.0 features are added to it. I think the alternative would be a separate annotation element <dfdl:version value="2"/> that is explicitly for this purpose, is allowed only at top level, etc. That would eliminate the complexity of getting a DFDLVersion by way of a dfdl:ref that includes a named format. It could be required to just be at lexical top level of every schema document that uses v2.0 features. The reason not to change namespaces, even though that is what we thought we should do originally, is based on various guidance such as http://www.xml.com/pub/a/2004/07/21/design.html These comments mostly apply to versioning of individual DFDL schemas, not of the schema-defining language itself. The quintessential example of a language version changing is XMLSchema itself which now has version 1.1. This still uses the same namespace as XMLSchema 1.0. 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, Jan 23, 2018 at 11:36 AM, Steve Hanson <smh(a)uk.ibm.com> wrote: > Mike, > > Your scheme as proposed has a couple of problems. > a) It is possible to create a schema that does not use dfdl:format at all. > Unlikely but possible. With such a schema there is no way to indicate > version. > b) What are the version implications for annotations that have nothing to > do with dfdl:format? Asserts, discriminators, variables. > > Most of the language you use refers to versions of *schemas*. That's not > the same as version of a dfdl:format. Any reason you didn't just change the > DFDL namespace URL to be *http://www.ogf.org/dfdl/dfdl-2.0/* > <http://www.ogf.org/dfdl/dfdl-2.0/>, which must be declared before any > DFDL feature can be used? I think that was always the intent of the DFDL > namespace. > > The key piece of work is validating any proposal against the scoping rules > in section 8 of the spec. > > Regards > > Steve Hanson > > IBM Hybrid Integration, Hursley, UK > Architect, *IBM DFDL* > <http://www.ibm.com/developerworks/library/se-dfdl/index.html> > Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/> > *smh(a)uk.ibm.com* <smh(a)uk.ibm.com> > tel:+44-1962-815848 <+44%201962%20815848> > mob:+44-7717-378890 <+44%207717%20378890> > Note: I work Tuesday to Friday > > > > From: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> > To: dfdl-wg(a)ogf.org > Date: 23/01/2018 16:03 > Subject: [DFDL-WG] Action Item: Versioning mechanism for DFDL v2.0 > features/changes > Sent by: "dfdl-wg" <dfdl-wg-bounces(a)ogf.org> > ------------------------------ > > > > > There are some features now under discussion which will most likely not be > part of the DFDL v1.0 standard, but a subsequent version 2.0 of the > standard. > > Implementations may have these features prior to the existence of that > draft version of the DFDL standard; hence, a mechanism for indicating the > support, and requirements that implies, on DFDL schemas is needed in order > for these v2.0 features to be introduced. > > The purpose of the versioning mechanism is to provide access to DFDL v2.0 > features, while maintaining also backward compatibility with DFDL v1.0 > schemas. > > For example, new DFDL format properties may be added to the DFDL v2.0 > version; however, those properties are not required to be specified unless > the version of the schema is specifically set to indicate it is using > version 2.0 features. Also, deprecated features should only generate > deprecation warnings if the user is requesting version 2.0 of DFDL, and > should be silent otherwise. > > Proposal: > > New attribute on the dfdl:format annotation: DFDLVersion with valid values > "1", "2". All values are reserved for future use. > > The DFDLVersion, if unspecified, defaults to "1" which means the > implementation is of the DFDL v1.0 specification. > > If the DFDLVersion is "2", then new requirements for version 2.0 of DFDL > may be enforced on the schema, and schema definition errors will result if > version 2.0 requirements are not met. DFDL Version 1.0 features that are > deprecated will generate warnings. > > Example: > > <dfdl:format DFDLVersion="2" .../> > > Example: > > <dfdl:defineFormat name="myV2Format"> > <dfdl:format DFDLVersion="2" .../> > </dfdl:defineFormat> > > The DFDLVersion is not a format property and is not scoped. It can be > added to a named format definition which is then referenced in the usual > manner for named format definitions. > > Backward Compatibility Requirement > > DFDL Implementations that provide version 2.0 functionality must also > provide DFDL v1.0 compatibility. That is, version 2.0 subsumes and extends > version 1.0. > > Mixed Version Schemas > > If a schema consists of multiple schema documents, and their respective > dfdl:format annotations do not all contain the same value for the > DFDLVersion attribute, then the schema is said to be "mixed version". This > is allowed. > > A named dfdl:format carrying DFDLVersion "2" may not be referenced from a > DFDL Schema document having DFDLVersion "1". > > The opposite is allowed: A named dfdl:format carrying DFDLVersion="1" or > lacking the DFDLVersion attribute may be referenced from a DFDL Schema > having DFDLVersion="2". > > There are really 3 ways that DFDL version 2.0 can differ from version 1.0, > and these are that new features are added, old features are deprecated, or > old features are removed. This latter is quite undesirable, but will be > considered a possibility for purpose of discussion this versioning system. > > These will commonly be in combination such as if an old feature is > deprecated with the replacement feature being added. > > These will now be discussed separately, with the emphasis on how mixed > version schemas must work. > > New Features Added > > Each new required DFDL property introduced for version 2.0 will be defined > along with what is called its "version 1.0 default value". When a mixed > version schema exists, the DFDL v1.0 parts of it behave as if any required > DFDLVersion 2 properties have their version 1.0 default value defined, at > top level of the schema (as if defined with that default value in each > DFDLVersion 1 schema document's dfdl:format annotation). > > Features Removed > > Incompatibilities are to be avoided wherever possible, and may not be > needed at all. However, there is still the possibility that some feature > will want to be entirely removed and replaced by something better, and in > that case the versioning scheme needs to be able to support this. > > In that situation, the schema definition error for version 2 is only > generated when a schema has DFDLVersion 2 specified (in dfdl:format > explicitly, or by reference to a named format carrying or referencing > DFDLVersion 2). Mixed schemas that contain schema documents entirely using > version 1 of DFDL do not generate this schema definition error. > > Features deprecated > > Deprecation warnings are generated only when a DFDLVersion="2" attribute > is present or is incorporated by reference (to a named format). A version 1 > schema that is incorporated with a version 2 DFDL schema but is not > modified in any way, does not generate deprecation warnings about version > 1.0 features that have been deprecated in version 2.0. > > (Most likely deprecations would be revising property names or value enums > for clarity.) > > Implementations may provide mechanisms for suppressing warnings. These are > implementation dependent. > > Version 1.0 Existing Deprecations and Compatibility > > During the process of standardization for DFDL v1.0 a number of properties > names were changed. DFDL version 1.0 implementations accept both the old > and new property names. > (Example: dfdl:separatorSuppressionPolicy, which replaced an older > property name.) DFDL schemas that specify DFDLVersion="2" will not accept > the older property names, and it is a schema definition error if the old > (pre DFDL v1.0) property names are used. > > Properly constructed mixed version schemas can still depend on the older > property names in the version 1.0 parts of the schema. > > ------------------------------ > > > Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | > *www.tresys.com* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.tresys.com&d=DwMFaQ…> > Please note: Contributions to the DFDL Workgroup's email discussions are > subject to the *OGF Intellectual Property Policy* > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.ogf.org_About_abt-5…> > -- > dfdl-wg mailing list > dfdl-wg(a)ogf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www. > ogf.org_mailman_listinfo_dfdl-2Dwg&d=DwICAg&c=jf_ > iaSHvJObTbx-siA1ZOg&r=AJa9ThEymJXYnOqu84mJuw&m=lDIa8xvu2n-e8 > PXWCJmajfYaXESMqvvOWpg1HMWeuGQ&s=hdO_VQ_p-1f7JfZPcSTPR1S_Y1a > nSBXJWarqPdJZdPc&e= > > 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 > >

2 6

clarification needed: section 14.2.1 potentially trailing group
by Mike Beckerle 15 May '18

15 May '18

Section 14.2.1 introduces the term "potentially trailing group". It is referred to only in the next paragraph which defines "Trailing or Actually Trailing". Presumably this was done because it was intended that separator suppression would consider a potentially trailing group to have some separator suppression behavior. However, all subsequent discussion of separator suppression I find discusses only separators between elements. So we should either drop "potentially trailing group" and its definition, and modify the definition of "Trailing or Actually Trailing" to specify only elements.... or fix everyplace where things are specific to elements to refer to terms (term meaning element or model group). I suggest it is ok to eliminate "potentially trailing group". First, it simplifies things. If you want separator suppression behavior, well it applies only to potentially trailing things, and those things must be elements. Since only elements can be optional (only elements can have min/max occurs in DFDL), this means if you want separator suppression behavior, the separated things must be elements, period. Any model group, regardless of whether it has framing syntax, zero-length, whatever, would be considered required, and elements prior to it within a sequence group could not be considered potentially trailing and so separatorSuppressionPolicy would never result in suppression. I do not think we lose any expressive power in DFDL by requiring separator suppression to work only on elements. It perhaps requires you to put an element decl around something you might not want to. But there are lots of things in DFDL that require use of extra tiers of elements. Daffodil does not implement potentially trailing model groups, or if it does, it's super buggy. DFDL4S is binary only so doesn't have this stuff. What does IBM DFDL do here? Do you allow a sequence like: <sequence> optional element A optional element B <sequence> optional element C </sequence> optional element D </sequence> to have separator suppression that applies to elements A and B, or only to element D ? Comments? 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 1

Feature needed: Possible Root element annotation
by Mike Beckerle 30 Mar '18

30 Mar '18

I think IBM DFDL already has this label. I think we need to standardize it as part of DFDL. Seems DFDL schemas, to make compilation feasible, and avoid many unnecessary warnings and spurious weirdness, must have a way of deciding what top level elements are intended to be Root elements. Some global element decls might have clearly upward-and-outward relative path expressions inside them, and such elements are unsuitable for use as root elements. We don't want to issue diagnostics for these unless the user expresses intent to use one of them as a root. In that case they have made a mistake and need a diagnostic. I believe one could sidestep the issue by only creating elements for things that could be roots, and use global types or global groups otherwise. But we have users who really want to use lots of global elements and element refs for their own reasons (they want the schema to have a certain regular structure for non-DFDL reasons) We definitely do see a need for many elements of a schema to be possible roots. This is particularly important for message-oriented formats where there is no natural root element that surrounds all the messages because they are arriving on a non-bounded stream that is effectively open "forever". 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

Proposal: Features to Support Table-Lookup
by Mike Beckerle 29 Mar '18

29 Mar '18

I'm seeking feedback on this proposal for a future feature in DFDL. The feature is intended to solve the problem of symbolic constants in data - enumerations which are strings with corresponding integer values, but also named numeric ranges. The proposal is here: https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Features+t… 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

Agenda for next OGF DFDL WG Call
by Steve Hanson 20 Mar '18

20 Mar '18

Please find agenda for call on Redmine at https://redmine.ogf.org/dmsf_files/13574?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

Confirmed: OGF DFDL Working Group Call (20 Mar 15:00 GMT)
by Steve Hanson 20 Mar '18

20 Mar '18

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

Latest OGF DFDL WG Call Minutes
by Steve Hanson 08 Mar '18

08 Mar '18

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

DFDL4S C++ 1.0 released
by Michele Zundo 07 Mar '18

07 Mar '18

Dear all, we have just publicly released the C++ version of our DFDL4S Java library to read/write binary data using DFDL schema. It implements only a subset of DFDL standard but enough for our use (read/write of CCSDS formatted data). Details and download from https://eop-cfi.esa.int/ <https://eop-cfi.esa.int/>. ESA - European Space Agency Michele Zundo Head of Ground System Definition and Verification Office System Support Division Earth Observation Project Department Directorate of Earth Observation Programmes ESTEC Kepleerlaan 1, 2200AZ Noordwijk, Netherlands michele.zundo(a)esa.int <mailto:michele.zundo@esa.int> | www.esa.int <file:///x-msg/::11:www.esa.int> T. +31 71 565 3924 | F +31 71 565 3171

3 2

Confirmed: OGF DFDL Working Group Call (6 Mar 15:00 GMT)
by Steve Hanson 06 Mar '18

06 Mar '18

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