This action item is about how we operate our workgroup going forward, and
how that evolves now that we're an ISO/IEC standard as well as an OGF one.
I believe we will need to create a workgroup document describing these new
practices, particularly when they augment/vary some of the standard OGF
practices.
Please add to this list of issues about how we operate going forward.
- Typography: I assume we have to revise the OGF Spec to match Standard
ISO format (Beyond just A4 page size) so future versions come out in that
conforming style.
- Once we do this I don't want to be maintaining an OGF flavor and an
ISO flavor of the formatting.
- Does a preliminary working document of the DFDL workgroup have to
be specifically marked as such (so that it is clearly preliminary)? What
are these markings?
- If that is done without revisions of content from current OGF
content, would that replace the current ISO-provided document (which is
just a new cover page on our existing OGF GFD.240 document) or does that
wait for a content revision?
- Who are contacts within JTC1 ? Does the OGF Workgroup contact JTC1 by
way of OGF leadership or directly? (or... what is the chain of command
here? Don't want to be jumping across protocol boundaries!)
- Is there a TC within JTC1 that we should work more closely with? Right
away? Eventually? Need contacts there.
- In 6 years a PAS is supposed to become an International Standard. What
does that mean? Does PAS status end? Does OGF participation end, or does
the workgroup merge into a TC? Or is this just a status change assuming
things are going well?
- Day to day working group activity/meetings - is there guidance about
notes/minutes-taking, etc. (templates)?
- Such time as we have revisions to the document, how do we engage with
ISO to get an update to the PAS document? Are these voted?
- What about just typographical corrections?
- Thoughts: Do we just use the OGF process for updates/corrections
and then just submit the changes to JTC1 (some TC?) for consideration?
Mike Beckerle
Apache Daffodil PMC | daffodil.apache.org
OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl
Owl Cyber Defense | www.owlcyberdefense.com
I'm interested in what DFDL implementations support element references?
IBM ACE?
IBM zTPF?
DFDL4Space?
Can you let me know whether these implementations support element refs?
The reason I ask is below, which may be of interest or perhaps TL;DR.
We support element references in Daffodil, but I'm coming around to the
view that element refs are a bad idea in DFDL schemas.
They're not needed for any specific data format expressive power. That
suggests we should have left them out of DFDL, but for some reason we
didn't.
The problem is that most data languages have nothing like element
references and the associated element namespace management complexity
available.
So as soon as you want to use a DFDL schema but not use it to interchange
data as XML, element refs become a problem.
I'm playing around with a best practice/subset/profile suggestion where:
* The only global element declarations in the schema are for root elements.
* Element references are disallowed
* The root elements are declared in a root schema file that contains ONLY
the root elements
* Root elements should always be declared by one-liners like this:
`<element name="rootElement" type="prefix:rootElementType"/>`
* The root elements schema file has no target namespace.
* All group, type, and DFDL format/escapeScheme/variable definitions must
be declared in different schema files that may (and probably should) have a
target namespace.
The benefit of these restrictions is that the elements in the nest of a
DFDL infoset never have any namespaces.
This makes them compatible with non-namespaced data systems like JSON,
Apache Drill, Apache NiFi, Generated C code, etc.
This makes integration with those things *massively* simpler.
Such schemas are still easily reused by reusing the type of the root
element, so there is no need to ever use an element reference, and a nice
composition property occurs - you don't need element references to assemble
schemas from component schemas, and the assembled component has the same
characteristic.
There are a few other things this discipline also simplifies. Reusing test
data becomes simpler if namespace URIs aren't getting embedded in every
test infoset XML file, for example.
All comments are welcome.
Mike Beckerle
Apache Daffodil PMC | daffodil.apache.org
OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl
Owl Cyber Defense | www.owlcyberdefense.com
I believe the requested agenda topic for the May 8 call was discussion of
DFDL 2.0 and/or DFDL 1.1?
Please circulate emails about topics in that area you'd like to discuss on
the call, or generally.
There is a problem called the "second system effect" I think which is when
version 2.0 never happens because the team wants to fix every single thing
wrong with version 1.0, and perfectionism sets in.
We want to avoid that.
There is also a role for what I would call "standard profiles" which are
knobs to turn to tell a DFDL processor that you want to limit your DFDL
usage so that your schemas will have certain standard behaviours.
An example is to disallow elements to be distinguished only by namespace,
so that the DFDL schema can be used to convert data to/from JSON or other
data frameworks where elements have only names, and there is no notion of
namespaces for names. We've run into this in JSON and a major integration
of Daffodil with Apache Drill. DFDL users would benefit from a way to say
"keep me out of namespace troubles" like that.
Mike Beckerle
Apache Daffodil PMC | daffodil.apache.org
OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl
Owl Cyber Defense | www.owlcyberdefense.com
