[DFDL-WG] Latest draft of DFDL 1.0 specification - trackers created

[Mike Beckerle]

I've attached the spec to the tracker for it.

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 Fri, Sep 13, 2013 at 7:17 AM, Steve Hanson <smh at uk.ibm.com> wrote:

> Greg, Alan
>
> Thanks for the advice. I have read the page and also GFD.152. I have
> created the following:
>
> 1) https://redmine.ogf.org/issues/117: DFDL 1.0 Specification (revision)
> - GWD-PR
> - Hoping Mike will be able to attach the document later today
>
> 2) https://redmine.ogf.org/issues/118: DFDL 1.0 Experience document #1
> - GWD-E
> - Document attached
>
> 3) https://redmine.ogf.org/issues/119: DFDL 1.0 Experience document #2
> - GWD-E
> - I will attach document later today
>
> I marked 2 and 3 as 'High priority' but can't update 1 to be the same.
>
> Regards
>
> Steve Hanson
> Architect, IBM Data Format Description Language (DFDL)
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK*
> **smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:+44-1962-815848
>
>
>
> From:        "Sill, Alan" <alan.sill at ttu.edu>
> To:        Greg Newby <gbnewby at alaska.edu>,
> Cc:        "Sill, Alan" <alan.sill at ttu.edu>, Steve Hanson/UK/IBM at IBMGB, "
> dfdl-wg at ogf.org" <dfdl-wg at ogf.org>, "David E. Martin" <
> martinde at northwestern.edu>
> Date:        12/09/2013 22:50
> Subject:        Re: Latest draft of DFDL 1.0 specification
> ------------------------------
>
>
>
> Thanks, Greg.
>
> Steve, that link to the Editor project is
> http://redmine.ogf.org/projects/editor
>
> You may be interested in pointing your members to the overall description
> of the different types of OGF documents and their use, along with various
> other useful links including copies of the document template that include
> the latest IPR boilerplate, at the link below.
>
> http://redmine.ogf.org/projects/editor/wiki/About_OGF_Documents
>
> I recommend that everyone involved read this page.
>
> As we are meeting for the GFSG this coming Sunday in Madrid, getting
> something in front of us that we can act on then, at least to get the
> review process started, would be the most expeditious way to proceed.
>
> Hope this helps,
> Alan
>
> On Sep 12, 2013, at 1:07 PM, Greg Newby <gbnewby at alaska.edu>
> wrote:
>
> > Understood, and no problem for pre-allocating a number. Would you
> > please make a new tracker in the Editor pipeline, so I can put the number
> > there?  That's where we keep track of assigned numbers.  It's ok
> > if you don't add the draft document yet.
> >
> > The idea of an expedited review process seems reasonable to me.  Once
> > we have the document, we can bring that suggestion to the GFSG for
> > their decision on how to handle it.  I'm sure they'll be receptive.
> >
> >  -- Greg
> >
> > On Thu, Sep 12, 2013 at 09:52:23AM +0100, Steve Hanson wrote:
> >> Greg
> >>
> >> GFD.152 implies that there is a 15-day GFSG review followed by a 60-day
> >> public comment period. We had a public comment period for GFD.174, and
> the
> >> changes in the revision are based on actual experience from
> implementers
> >> and users.  I would question whether the public comment period is
> >> necessary for the revision, and request that the revision just
> undergoes
> >> the 15-day GFSG review. There will no doubt be a few more errata as
> >> implementations progress further, and so we anticipate one more
> revision
> >> at some point in the future, and that is the revision that would move
> to
> >> full Grid Recommendation.
> >>
> >> We are on a tight schedule and want to publish by end of September. We
> >> have users eagerly awaiting the appearance of the revision, and to
> publish
> >> an internal WG draft is not appropriate (IBM product infocenters embed
> the
> >> HTML rendering of the spec so needs to be official document).
> >>
> >> We requested the GFD number simply so that Mike Beckerle can complete
> the
> >> document edits. The document pushes the boundaries of MS Word and I
> think
> >> Mike also uses an additional plugin, so edits are best done by him.
> >>
> >> Regards
> >>
> >> Steve Hanson
> >> Architect, IBM Data Format Description Language (DFDL)
> >> Co-Chair, OGF DFDL Working Group
> >> IBM SWG, Hursley, UK
> >> smh at uk.ibm.com
> >> tel:+44-1962-815848
> >>
> >>
> >>
> >> From:   Greg Newby <gbnewby at alaska.edu>
> >> To:     Steve Hanson/UK/IBM at IBMGB,
> >> Cc:     "Sill, Alan" <alan.sill at ttu.edu>, "dfdl-wg at ogf.org"
> >> <dfdl-wg at ogf.org>, "David E. Martin" <martinde at northwestern.edu>
> >> Date:   11/09/2013 21:07
> >> Subject:        Re: Latest draft of DFDL 1.0 specification
> >>
> >>
> >>
> >> Steve,
> >>
> >> Is this document in the editor pipeline somewhere?  I'm
> >> not seeing it:
> >>  https://redmine.ogf.org/projects/editor/issues
> >>
> >> Usually we wait until a document has undergone most of the
> >> review process (per GFD #152) before assigning a GFD number.
> >> If you have a reason to need one sooner, we can allocate
> >> one sooner.  The usual practice, though, is to wait until
> >> publication is imminent.
> >>
> >> We're looking forward to these revisions to #174.
> >>  -- Greg
> >>
> >> On Wed, Sep 11, 2013 at 06:08:36PM +0100, Steve Hanson wrote:
> >>> Alan, Greg
> >>>
> >>> Please can you allocate us a new GFD number so we can complete the
> >>> document?
> >>>
> >>> Regards
> >>>
> >>> Steve Hanson
> >>> Architect, IBM Data Format Description Language (DFDL)
> >>> Co-Chair, OGF DFDL Working Group
> >>> IBM SWG, Hursley, UK
> >>> smh at uk.ibm.com
> >>> tel:+44-1962-815848
> >>>
> >>>
> >>>
> >>> From:   "Sill, Alan" <alan.sill at ttu.edu>
> >>> To:     Steve Hanson/UK/IBM at IBMGB,
> >>> Cc:     "Sill, Alan" <alan.sill at ttu.edu>, "dfdl-wg at ogf.org"
> >>> <dfdl-wg at ogf.org>, Greg Newby <gbnewby at alaska.edu>, "David E. Martin"
> >>> <martinde at northwestern.edu>
> >>> Date:   11/09/2013 15:49
> >>> Subject:        Re: Latest draft of DFDL 1.0 specification
> >>>
> >>>
> >>>
> >>>
> >>> On Sep 11, 2013, at 9:08 AM, Steve Hanson <smh at uk.ibm.com>
> >>> wrote:
> >>>
> >>>> When you say 'new version' what does that imply about version
> numbers?
> >>
> >>> The WG still considers what we are working on to be DFDL 1.0 plus
> >> errata.
> >>> Are you suggesting that the new revision is 1.1 ?
> >>>
> >>> OGF doesn't generally have a concept or framework for revision numbers
> >> for
> >>> specifications. Some working groups do number their specifications,
> and
> >> we
> >>> leave this to the work group to manage.
> >>>
> >>> The process of obsoleting and replacing a document does give a good
> >>> opportunity for changing an internally-managed revision number.
> >>>
> >>> Regarding the next DFDL call, this will be during OGF 39. I could try
> to
> >>
> >>> join, but that time overlaps one of the sessions that I should attend.
> >>> Perhaps David or Greg (or both) could attend your call at 16:00 Tues
> >> 17th
> >>> September?  If so, please provide details.  We'll be happy to
> >> communicate
> >>> with you as much as possible on this topic before then, of course.
> >>>
> >>> Alan
> >>>
> >>>
> >>> ----- Forwarded by Steve Hanson/UK/IBM on 11/09/2013 16:35 -----
> >>>
> >>> From:   Steve Hanson/UK/IBM
> >>> To:     "Sill, Alan" <alan.sill at ttu.edu>,
> >>> Cc:     "Sill, Alan" <alan.sill at ttu.edu>, "dfdl-wg at ogf.org"
> >>> <dfdl-wg at ogf.org>, Greg Newby <gbnewby at alaska.edu>, "David E. Martin"
> >>> <martinde at northwestern.edu>
> >>> Date:   11/09/2013 15:08
> >>> Subject:        Re: Latest draft of DFDL 1.0 specification
> >>>
> >>>
> >>> Alan
> >>>
> >>> Thanks for your reply. I forgot to say that the next call is on Tues
> >> 17th
> >>> September.
> >>>
> >>> I think that the WG would probably go for your 2nd suggestion, ie,
> >> publish
> >>> an updated P_REC that obsoletes GFD.174 but does not yet propose to
> >>> promote the spec to full recommendation status, because we know there
> >> are
> >>> a few more errata that will be discovered before the implementations
> are
> >>
> >>> completed.
> >>>
> >>> When you say 'new version' what does that imply about version numbers?
> >> The
> >>> WG still considers what we are working on to be DFDL 1.0 plus errata.
> >> Are
> >>> you suggesting that the new revision is 1.1 ?
> >>>
> >>> Regards
> >>>
> >>> Steve Hanson
> >>> Architect, IBM Data Format Description Language (DFDL)
> >>> Co-Chair, OGF DFDL Working Group
> >>> IBM SWG, Hursley, UK
> >>> smh at uk.ibm.com
> >>> tel:+44-1962-815848
> >>>
> >>>
> >>>
> >>> From:   "Sill, Alan" <alan.sill at ttu.edu>
> >>> To:     Steve Hanson/UK/IBM at IBMGB, "David E. Martin"
> >>> <martinde at northwestern.edu>,
> >>> Cc:     "Sill, Alan" <alan.sill at ttu.edu>, "dfdl-wg at ogf.org"
> >>> <dfdl-wg at ogf.org>, Greg Newby <gbnewby at alaska.edu>
> >>> Date:   11/09/2013 14:51
> >>> Subject:        Re: Latest draft of DFDL 1.0 specification
> >>>
> >>>
> >>>
> >>> Steve,
> >>>
> >>> Answers inline. Short summary: My recommendation would be to publish a
> >> new
> >>> version that obsoletes the current GFD.174, and optionally to use this
> >>> opportunity to migrate the specification from a P-REC to full REC
> >> status.
> >>> This would be facilitated by documenting, in any form that is
> convenient
> >>
> >>> including but not limited to an informational GFD, the experience
> gained
> >>
> >>> from implementations to date. Another option is to publish an updated
> >>> P_REC that obsoletes GFD.174 but does not yet propose to promote the
> >> spec
> >>> to full recommendation status.
> >>>
> >>> On Sep 11, 2013, at 6:47 AM, Steve Hanson <smh at uk.ibm.com>
> >>> wrote:
> >>>
> >>>> Alan
> >>>>
> >>>> Since the DFDL 1.0 specification was published in Feb 2011, the two
> >>> implementation teams (IBM and the Daffodil project) have identified a
> >>> number of errata in the specification. These have been recorded in an
> >>> errata document held on Redmine. The number of errata is currently at
> >>> around 190, and include both clarifications to the specification and
> >>> changes that affect an implementation, both major and minor. Typically
> >> as
> >>> errata have been raised, the implementation teams include any implied
> >>> changes in the next release of their implementation.
> >>>
> >>> Is there any documentation as to the experience gained from
> >>> implementations that has led to these updates? I as not as an OGF
> >>> requirement, but just for information.
> >>>
> >>>> Both implementation teams, and users of the two implementations, have
> >>> requested that the DFDL 1.0 specification is revised to include all
> >> errata
> >>> to date, so that the specification more closely reflects the
> >>> implementations. Accordingly all errata to date have been incorporated
> >>> into a new revision of the specification, which as a result has grown
> >> from
> >>> 168 pages to 234 pages.
> >>>>
> >>>> This new revision of the specification supersedes the original.
> >>>
> >>> This statement is what leads to my suggestion to publish a new
> document.
> >>
> >>> Note that our procedures do allow for replacement of a REC or P-REC
> for
> >>> non-normative changes that do not substantially affect compatibility
> of
> >>> implementations, but that just clarify or correct errors in the
> original
> >>
> >>> publication. It is the statement that the new revision supersedes the
> >>> original coupled with your earlier observation that major
> implementation
> >>
> >>> issues are addressed in your new version that causes me to suggest
> that
> >>> you pursue a new GFD that obsoletes the old one.
> >>>
> >>>> There is no implementation that exactly reflects the original as
> >>> published on the OGF web site, they both adhere more closely to the
> new
> >>> revision. The DFDL WG would therefore like to publish the new
> revision.
> >>> The DFDL WG also recognises that there may be comments against the new
> >>> revision, and that there may still be some errata undetected by the
> >>> implementation teams, so that a further revision may be necessary in
> the
> >>
> >>> future. Nonetheless it is important that the new revision in its
> current
> >>
> >>> form is externally visible, and not just kept as an internal working
> >>> document, as there are now many dozens of DFDL users, and they need an
> >>> up-to-date specification. In particular, IBM DFDL wants to ship the
> HTML
> >>
> >>> version of the new revision to IBM customers in its next release.
> >>>>
> >>>> We are looking to the OGF for guidance on how next to proceed.
> >>>
> >>> My guidance would be to publish a new version that obsoletes the old
> >> one,
> >>> and optionally to use this opportunity to advance the specification
> from
> >>
> >>> P-REC to REC status.  Note that this is exactly the pattern that OGF
> >>> documents are supposed to follow in the life cycle described in
> GFD.152
> >> --
> >>> experience gained fro real-world implementation is fed back to produce
> a
> >>
> >>> new version of the specification, which at some point can declare
> itself
> >>
> >>> to be mature enough to request full REC status.
> >>>
> >>> As for further revisions, they would be handled by the procedure I
> >>> mentioned above: non-normative changes can be folded in as corrections
> >>> through the errata process. THis is controlled by the OGF editor (Greg
> >>> Newby) and whether to accept and publish an errata is decided
> >> essentially
> >>> entirely by his recommendation to the GFSG (Standards Council) to do
> so.
> >>
> >>> If the changes would affect the interoperability of implementations
> >>> written to the earlier spec in a substantial way, they should be
> handled
> >>
> >>> by the process of a new publication that obsoletes the old one, as we
> >> have
> >>> just discussed.
> >>>
> >>> The process of going from a P-REC to a REC is largely decoupled from
> >>> errata revisions, but as I have tried to point out, you may be in a
> >>> position do do this at thei point - especially if the group were to
> >>> publish its experiences with the spec as one or more informational
> >>> documents to provide a paper trail motivating the proposed changes.
> >> (This
> >>> part is your choice on how to produce the documentation, which does
> not
> >>> have to be in the form of a GFD but can and often is done this way.
> The
> >>> experiences of each group can be jointly or separately documented, at
> >> your
> >>> group's choice.)
> >>>
> >>>> Would it be possible for the OGF to join our next DFDL WG call to
> >>> discuss further? The call is at 16:00 UK (11:00 Eastern).
> >>>
> >>> If today, I can do this if you provide connection details. I include
> >> David
> >>> Martin in this reply in case he is available.
> >>>
> >>> Alan
> >>>
> >>>> Regards
> >>>>
> >>>> Steve Hanson
> >>>> Architect, IBM Data Format Description Language (DFDL)
> >>>> Co-Chair, OGF DFDL Working Group
> >>>> IBM SWG, Hursley, UK
> >>>> smh at uk.ibm.com
> >>>> tel:+44-1962-815848
> >>>> 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
> >>>
> >>>
> >>>
> >>> 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
> >>>
> >>> 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
> >>
> >>
> >>
> >> 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
>
>
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20130913/4196cc24/attachment-0001.html>