The "format info" PR may have performance impact that would need to be fixed 
before 2.1. That's ok. I'd rather merge it, then put it under the microscope to 
identify and fix performance issues rather than keep this large change 
outstanding any longer.


re: NATO fix - yes query style expressions are the general capability that 
fixes this.


I have a "hack" fix for this - It simply removes the check when the schema 
compiler detects /foo/bar when there is more than one bar element. Without that 
check, then at runtime you will always just get the value of the first bar 
element.


This is a small change, and can be reviewed at:


https://github.com/mbeckerle/incubator-daffodil/pull/2


This is all in my incubator fork, i.e., not a real PR on daffodil, because I've 
built this change on top of other work not yet merged.


I'm curious how much more work there is to really do query-style expressions.


________________________________
From: Steve Lawrence <slawre...@apache.org>
Sent: Thursday, January 4, 2018 11:00:33 AM
To: dev@daffodil.apache.org; Mike Beckerle
Subject: Re: Roadmap for next Daffodil releases

I think this seems like a reasonable roadmap with the right priorities.

Regarding 2.1.0:

I think all our current pull requests (except for maybe the packed/zoned
stuff?) are close to being merged in and can make 2.1.0.

I've got a patchset ready that changes to the apache namespace/license
which we can apply now that the SGAs are in. Once the existing PRs are
merged, I'll rebase the patchset onto that and do a pull request.

Regarding the NATO bug fix, is the right fix for this to support query
style expressions? The InfosetImpl already has the changes necessary to
support them. So it should just require changes to DPath to expect and
allow Sequences of DINodes rather than a single node. And most DPath
functions should just error if there is more than one element. It's
probably just the array handling/indexing that changes, and additional
validation that all types of same named elements are the same?. I don't
think the changes are trivial, but they should be mostly contained to DPath.

- Steve

On 12/22/2017 01:17 PM, Mike Beckerle wrote:
> We've had some people asking what our road map is for next releases.
>
>
> Here's my proposal. I'm open to suggestions to change, reorder, add, etc.. 
> The release numbering schema is of course subject to change.
>
>
> My planning horizon is about 6 months here.
>
>
> Release 2.1.0 - to contain critical patches needed by 2 of our user 
> communities (LWAP project, NATO).
>
>   *   Goal Timeframe: Jan 2018
>   *   This should be our first Apache Incubator release as we have all the 
> SGAs on file for Apache now.
>   *   LWAP bug fix (DAFFODIL-1864) is in & done
>   *   NATO bug fix 
> (DAFFODIL-1869<https://issues.apache.org/jira/browse/DAFFODIL-1869>) has yet 
> to be explored/reproduced. This is way overdue, as they reported the issue 
> last spring/early-summer.
>
>
> Release 2.2.0 - Three new important features
>
>   *   Goal Timeframe: March/April 2018
>
>   *   BLOB support (DAFFODIL-1735) - enables large image file formats
>   *   pre/post processor support (DAFFODIL-1734) - enables IETF format needs 
> like line folding, and base64 encoding
>   *   message streaming API (DAFFODIL-1065, DAFFODIL-1526, DAFFODIL-1799)
>      *   enables unbounded stream of input messages for parsing, output for 
> unparsing
>
>
> Release 2.3.0 - Interoperability
>
>   *   Goal Timeframe: June 2018
>   *   Implements features needed to demonstrate high degree of interop of the 
> two primary DFDL implementations which are IBM's and Daffodil.
>      *   Large number of JIRA tickets associated with this. Not going to 
> enumerate them here.
>
>
>
> Time frames are of course subject to the number of contributors working on it.
>
>
> My guesses/goals for time-frames are based on wanting to do a release about 
> every 2 or 3 months, and roughly the current number of active, up-to-speed, 
> contributors.  Our hope of course is to gather new contributors, which would 
> hopefully allow us to do more.
>
>
> The above really only discusses functional changes in Daffodil visible 
> features.
>
>
> The stretch goals for these releases include making progress on any of these 
> areas:
>
>   *   changes to reduce memory footprint and improve performance of the 
> schema compiler (DAFFODIL-1444)
>   *   usability improvements (diagnostics - 69 JIRA Tickets, debugger - 14 
> JIRA Tickets)
>   *   new DFDL language features (DAFFODIL-1782) to support integer 
> representations of logical strings with table-based translation. (Needed for 
> some schemas like STANAG 5516, VMF)
>   *   Expanded documentation of Daffodil internals - in code comments, and 
> outside of it (wiki)
>   *   DFDL tutorials and example schemas
>   *   Reduce bug backlog (198 JIRA Tickets) and the 236 TODOs and FIXMEs in 
> the code (DAFFODIL-1569)
>   *   Some code cleanups/simplifications (45 JIRA Tickets labeled "Clean Ups" 
> component)
>
>
>
>

Reply via email to