- dfdl-wg - lists.ogf.org

clarification needed: prefixLengthType has min/max facets prefixIncludesPrefixLength="yes"
by Mike Beckerle 14 Nov '24

14 Nov '24

(Note: email sent to dfdl-wg at lists.ogf.org, not just ogf.org per prior practice.) Sometime back, in order to allow facets to sanity check prefix length values, we specified that if facets are expressed on a prefixLengthType they would always be checked and if they do not hold it is a processing error. This correction was part of the most recent GFD.240 However, we did not specify if the facet check is done on the prefix length value before or after it is adjusted when prefixIncludesPrefixLength="yes". So for example, suppose there is a single-byte prefix on a string and dfdl:prefixIncludesPrefixLength is "yes". Then the minimum well-formed value of the prefix is "1" which indicates a length 0 string with a single byte prefix. Suppose I want to add XSD facets to sanity check this prefix value: <simpleType name="prefix1Byte"> <restriction type="xs:unsignedByte"> <maxInclusive value="99"/> </restriction> </simpleType> So, if this type is used as the dfdl:prefixLengthType of a string with dfdl:lengthKind='prefixed', and dfdl:prefixIncludesPrefixLength="yes" then does the check for 99 measure the length of the string, or the value of the prefix, which is the length of the string plus one? My thought is that there is a quasi-element corresponding to this single byte prefix. That quasi-element's value is what is constrained by this maxInclusive facet. So I'm claiming the facet value 99 should be compared against the stored value in the prefix quasi-element, that is before any value adjustment is done for dfdl:prefixIncludesPrefixLength. Which is to say, suppose you switched to dfdl:lengthKind="explicit", and made an actual element of the single unsiged byte "prefix" field. Then the adjusting for the length of that prefix length would be done in the dfdl:length expression for the string, and the dfdl:outputValueCalc for the single byte prefix field. Which is to say that facets constraining the value of that one-byte element would apply to the value directly, not after any adjustment. I think lengthKind prefixed should work exactly the same as when a real length element and outputValueCalc are used. One should not have to adjust facets on the type of the length field when when it is the type of the length element, no should one have to adjust the facets if you convert and use lengthKind 'prefixed' with the dfdl:prefixLengthType, the facets should mean the same thing. Any thoughts/comments? Note: daffodil PR about this: https://github.com/apache/daffodil/pull/1334 JIRA Issue: https://issues.apache.org/jira/browse/DAFFODIL-2660

2 2

Agenda for call on 2024-11-14
by Mike Beckerle 14 Nov '24

14 Nov '24

See: https://github.com/OpenGridForum/DFDL/blob/master/calls/2024/2024-11-14_DFD… 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

1 0

DFDL-WG: Call for Agenda Topics for Meeting/Call on Nov 14
by Mike Beckerle 07 Nov '24

07 Nov '24

Call for agenda items/topics for November Workgroup Call. I have two minor clarification issues that have come up in email: * decimalSigned * prefixLengthType Please send other agenda items you would like to discuss. 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

1 0

DFDL-WG Call/Meeting 2024-10-10 Agenda & Minutes
by Mike Beckerle 14 Oct '24

14 Oct '24

Due to mailing list bounces, this is going out after the fact. Apologies. Mail to dfdl-wg at lists.ogf.org appears to work properly. Here is the agenda and minutes for 2024-10-10 https://github.com/OpenGridForum/DFDL/blob/master/calls/2024/2024-10-10_DFD… Here is the minutes from 2024-09-12 Call: https://github.com/OpenGridForum/DFDL/blob/master/calls/2024/2024-09-12_DFD… Mike Beckerle OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Apache Daffodil PMC | daffodil.apache.org Owl Cyber Defense | www.owlcyberdefense.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

[ANNOUNCE] Apache Daffodil 3.8.0 Released
by Mike Beckerle 14 Jun '24

14 Jun '24

The Apache Daffodil community is pleased to announce the release of version 3.8.0. Notable changes in this release include a supported API for Daffodil layers. Layers are a Daffodil extension to the DFDL language which are small algorithmic code plugins for computing checksums/CRCs on regions of data, or for performing data encoding/decoding such as base64, line folding, or compress/decompress on regions of data. Detailed release notes and downloads are available at: https://daffodil.apache.org/releases/3.8.0/ Apache Daffodil is an open-source implementation of the DFDL specification ... y'all know this. https://daffodil.apache.org/ Regards, The Apache Daffodil Team

1 0

Canceled event with note: DFDL Workgroup - DFDL Spec Issues and Actions @ Thu Jul 11, 2024 11am - 12pm (EDT) (dfdl-wg@ogf.org)
by Mike Beckerle 13 Jun '24

13 Jun '24

This event has been canceled with a note: "Cancelled July meeting. Next meeting in August. " DFDL Workgroup - DFDL Spec Issues and Actions Thursday Jul 11, 2024 ⋅ 11am – 12pm Eastern Time - New York Location Google Meet https://www.google.com/maps/search/Google+Meet?hl=en Join with Google Meet https://meet.google.com/ifg-hknz-ysw?hs=224 Please send email to open discussions and add agenda for this meeting. If there are no specific topics I will cancel the meeting. Organizer Mike Beckerle mbeckerle.dfdl(a)gmail.com Guests Mike Beckerle - organizer frostmar(a)uk.ibm.com Mike Beckerle - optional smhdfdl(a)gmail.com - optional jens.jensen(a)stfc.ac.uk - optional alan.sill(a)ttu.edu - optional mbeckerle(a)owlcyberdefense.com - optional braddk(a)us.ibm.com - optional dfdl-wg(a)ogf.org - optional wiloneil(a)uk.ibm.com - optional wolfgang.ziegler(a)z-rands.de - optional ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 0

Topic: Creating ISO document from XML source
by Mike Beckerle 06 Jun '24

06 Jun '24

A goal/need is for our next revision of the DFDL spec to be in ISO format. Bill Ash (ISO JTC1 SC38) put me in contact with Jim Melton (ISO SQL standard) about their process which starts from an XML source to create their document. Jim has passed along a chapter of their XML, the XSLT, and other documentation about how they do it, which we can learn from. Below is the email thread with Jim Melton. I'm putting the zip-file attachment materials mentioned into our github repo. Now all we have to do is somehow convert the DFDL v1.0 MS-Word document into a marked up XML. Interestingly, practices for doing this kind of thing to large data format specifications at my employer are to first convert the MS-Word to text using PDFBox, then use DFDL to mine the text. The resulting DFDL infoset is converted to XML, then Scala or XSLT or both transformations can turn it into something maintainable. ---------- Forwarded message --------- From: Jim Melton <SheltieJim(a)xmission.com> Date: Thu, Jun 6, 2024 at 12:46 PM Subject: Re: Creating ISO document from XML source To: <mbeckerle(a)apache.org> Cc: <SheltieJim(a)xmission.com> Mike, Sorry I took several days to reply, but I'm leaving for a WG 3 meeting in China today and have been busy preparing for that meeting. I've attached a ZIP file to this message. In that ZIP archive, you will find some XML files and some XSL (XSLT, actually) files, as well as a DTD. These should have enough information to give you an idea of how we're using XML. The ZIP also contains some HTML files (generated from MarkDown) that serve as our documentation. The file named sql-psm.xml is the source file for one part of the SQL standard, ISO/IEC 9075-4:2023. I did not include the PDF that results from compiling sql-psm.xml, in large part because it's over 7MB. If you want that file, I can send it separately, but not for a couple of days (because I'm leaving shortly for the airport). If you want to talk about any of this, ask questions about how/why we did something, etc., I'll be back from China on June 17 or 18. Hope this helps, Jim On 2024-06-03 09:31, Mike Beckerle wrote: Jim, Sure. Please send the bundle of things you suggested would be of interest. We can start by looking at what you have done and seeing how our situation matches and differs. If it's too large for a single big zip attachment, you can split it up how you like, or we can come up with some alternative path. Thank you Mike Beckerle On Fri, May 31, 2024 at 4:11 PM Jim Melton <SheltieJim(a)xmission.com> wrote: > > Mike, > > Pleased to meet you 😉 > > In JTC 1/SC 32/WG 3, we never developed our standards in Word, although other WGs in SC 32 do so. ISO/IEC 9075 (Database language SQL) was originally developed in some primitive IBM markup language whose name I have forgotten. When I became editor of the standard, I converted it to an "SGML-like" product named DECdocument (I worked at Digital Equipment Corp at the time). Later, after I left Digital, I converted the DECdocument markup to XML, created an XML vocabulary (in the form of a DTD), generated XSL-FO from the XML, then found a rendering engine (XEP, by RenderX) to convert to final PDF form. > > At this point (mid-2024), we have a highly functional system that generated PDF documents with massive numbers of internal and inter-document hot links, smaller "pointer documents" that allow a given document to be referenced in multiple meetings without duplicating the storage, artifacts (such as the BNF of the language), etc. We also have numerous programs doing source code validity checking (i.e., following our coding standards and ISO's Directives). I realize that not everything we have done will be relevant to other standards, but it will provide assistance in figuring out how to do what you want and may serve as a starting point for you. > > I would be happy to send you a standard document in both PDF and XML versions, as well as the DTD and primary stylesheets, and a MarkDown document that explains our coding standards and more. Just let me know! And, of course, I'm happy to answer any questions you might have about all of this stuff. > > Hope this helps, > Jim > > On 2024-05-31 09:15, Mike Beckerle wrote: > > Jim, > > I have heard you have an ISO-document creation system that starts from an XML source. > > We have a monster MS-Word document that is unwieldy, and not useful for generating any other formal artifacts. > > I hope to convert it to XML and then generate the ISO document from that XML, as well as other artifacts like online-doc for GUIs, annotated versions of the spec, etc. > > Can you point me at how your team(s) work uses XML? > > Any help greatly appreciated. > > Mike Beckerle > OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl > Apache Daffodil PMC | daffodil.apache.org > Owl Cyber Defense | www.owlcyberdefense.com > > -- > Jim Melton SheltieJim at xmission dot com > ------------------------------------------- > Owner and Captain: > Passport 40 #018 Dream SeQueL > Co-Owner and Co-Captain > Passport 42 #040 Turtle Blues > ------------------------------------------- > Shelties since 1969; ASSA member since 1992 -- Jim Melton SheltieJim at xmission dot com ------------------------------------------- Owner and Captain: Passport 40 #018 Dream SeQueL Co-Owner and Co-Captain Passport 42 #040 Turtle Blues ------------------------------------------- Shelties since 1969; ASSA member since 1992

1 1

Action 322: StringAsXML Experience Document
by Mike Beckerle 06 Jun '24

06 Jun '24

See this Pull Request: https://github.com/OpenGridForum/DFDL/pull/57 to comment, or this to read the document: https://github.com/OpenGridForum/DFDL/blob/4b1f50220ee064f662e6fe1339f84916… 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

1 0

Action 337: ISO DFDL Workgroup Operation changes
by Mike Beckerle 20 May '24

20 May '24

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

1 1

DFDL implementation support for element refs
by Mike Beckerle 09 May '24

09 May '24

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

2 3