See http://forge.gridforum.org/docman2/ViewCategory.php?group_id=113&category_id=803&language_id=1&sort0=ddate&dir0=1 The document is "DFDL Proposal" and is posted in word and pdf formats. If you use the above URL it should be the top 2 documents on your display. We made the official deadline which means I can really needle people to study this document and comment on it on or before GGF15. A couple of notes: My group at IBM produced this draft. While we tried to fold in the viewpoints of others at IBM that we have been working with over the past few months, I cannot represent that this document reflects any overall consolidated "IBM opinion" on DFDL at this time. There hasn't been time for the rounds of IBM-internal review that would require. Rather this is my group's take on things. It reflects our best shot at how to combine the concepts of the OMG TD model and its attributes with the rest of the DFDL concepts. We updated the scoping proposal to fix some ambiguities left over from the F2F last may, and there's a section on layering which only starts to tell the story about this powerful capability, but is a good start at it. There's a middle section which just gets started at the agenda of explaining all the subtlety of exactly how delimiting and tagging work, and how lengths and positions are determined and so forth. You'll see lots of TBDs and rationale discussion in here still. My goal is that by or at GGF15 we resolve many of these so these rationale blocks can move down into the appendices or into separate documents, allowing us to focus on the meat of specifying the core behavior more thoroughly. In the appendix which contains the rep-properties detail you'll see lots of conflicts. E.g., we have byteOrder=bigEndian/littleEndian AND we have bigEndian=true/false. This is intentional and is the remnants of joining forces with the OMG Type-descriptor model. We need to decide on these conflicts i.e., for each one, which way do we want to go. There are quite a few such conflicts to be resolved. Our prototype implementation does not implement exactly what is described in this draft, though it is quite close. The differences are fairly insignificant. I recommend grabbing the MSWord version, and inserting lots of comment blocks as you read it using the comments feature. It is a big document though (50 pages), and different parts of it are more accessible than others, so do what you will. Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA
Please expect an update to the doc draft. In reading a dead-tree version of the document I've discovered an annoying number of typographical snafus. Places where I expected to move something through cut and paste, but apparently copied instead, leaving the same content in 2 places. It's amazing how much more easily I read and spot these things on paper than on screen. Poor trees :-( I believe the document is readable as is, but I do want to fix up a few of these things as soon as I can. ...mikeb Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA Mike Beckerle/Worcester/IBM@IBMUS Sent by: owner-dfdl-wg@ggf.org 08/26/2005 06:26 PM To dfdl-wg@gridforum.org cc Subject [dfdl-wg] Draft document just under the wire for "official" commentary at GGF15 See http://forge.gridforum.org/docman2/ViewCategory.php?group_id=113&category_id=803&language_id=1&sort0=ddate&dir0=1 The document is "DFDL Proposal" and is posted in word and pdf formats. If you use the above URL it should be the top 2 documents on your display. We made the official deadline which means I can really needle people to study this document and comment on it on or before GGF15. A couple of notes: My group at IBM produced this draft. While we tried to fold in the viewpoints of others at IBM that we have been working with over the past few months, I cannot represent that this document reflects any overall consolidated "IBM opinion" on DFDL at this time. There hasn't been time for the rounds of IBM-internal review that would require. Rather this is my group's take on things. It reflects our best shot at how to combine the concepts of the OMG TD model and its attributes with the rest of the DFDL concepts. We updated the scoping proposal to fix some ambiguities left over from the F2F last may, and there's a section on layering which only starts to tell the story about this powerful capability, but is a good start at it. There's a middle section which just gets started at the agenda of explaining all the subtlety of exactly how delimiting and tagging work, and how lengths and positions are determined and so forth. You'll see lots of TBDs and rationale discussion in here still. My goal is that by or at GGF15 we resolve many of these so these rationale blocks can move down into the appendices or into separate documents, allowing us to focus on the meat of specifying the core behavior more thoroughly. In the appendix which contains the rep-properties detail you'll see lots of conflicts. E.g., we have byteOrder=bigEndian/littleEndian AND we have bigEndian=true/false. This is intentional and is the remnants of joining forces with the OMG Type-descriptor model. We need to decide on these conflicts i.e., for each one, which way do we want to go. There are quite a few such conflicts to be resolved. Our prototype implementation does not implement exactly what is described in this draft, though it is quite close. The differences are fairly insignificant. I recommend grabbing the MSWord version, and inserting lots of comment blocks as you read it using the comments feature. It is a big document though (50 pages), and different parts of it are more accessible than others, so do what you will. Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA
Greetings, Thanks for the updated draft! Now there is lot's of flesh on the bones. I have a very basic question (or maybe 2). Perhaps this has been discussed but simiply omitted from the document. On page 19, Section 12.2. of the 8-26 draft: "The primary purpose of complex types in a DFDL implmentation is to determine where their sub-elements begin and end in the data stream." 1. What is the definition of "a DFDL implementation"? (I suspect this is something like 'a program that uses DFDL schema to interpret a data object') 2. What is the definition of "the data stream"? The document seems to have many unstated assumptions about data streams, they seem to be continuous arrays of bytes, etc., they are byte addressable, etc. In other places, there are references to "a data file" p. 26, p. 27, and so on, and seems to assume that "stream" and "file" are the same thing. This becomes an issue when the stored representation 'on disk' isn't the same as the IO stream, e.g., data from a relational database. It would be good to try to clearly define these terms, perhaps with a model of IO WRT what DFDL is describing. Thanks for your attention. --REMcG --- Robert E. McGrath National Center for Supercomputing Applications University of Illinois, Urbana-Champaign Champaign, Illinois 61820 (217)-333-6549 mcgrath@ncsa.uiuc.edu
Here's a drafty agenda. More items in advance would be good. * status reports from PNNL-NCSA project - open source status, progress on features? any proposals forthcoming? * planning for upcoming GGF15 - who is planning to attend in person * Latest posted document - how do we structure discussion to this proposal? What do we do in advance of GGF15, what do we try to accomplish F2F at the GGF meeting. * GGF15 sessions - so far I've only reserved one 90 minutes session as a work session. Presumably we also need another 45min session as community outreach. (Deadline is friday to reserve.)
I updated the docs with my minor corrections. ...mikeb Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA Mike Beckerle/Worcester/IBM@IBMUS Sent by: owner-dfdl-wg@ggf.org 08/27/2005 10:58 AM To Mike Beckerle/Worcester/IBM@IBMUS cc dfdl-wg@gridforum.org, owner-dfdl-wg@ggf.org Subject Re: [dfdl-wg] Draft document just under the wire for "official" commentary at GGF15 Please expect an update to the doc draft. In reading a dead-tree version of the document I've discovered an annoying number of typographical snafus. Places where I expected to move something through cut and paste, but apparently copied instead, leaving the same content in 2 places. It's amazing how much more easily I read and spot these things on paper than on screen. Poor trees :-( I believe the document is readable as is, but I do want to fix up a few of these things as soon as I can. ...mikeb Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA Mike Beckerle/Worcester/IBM@IBMUS Sent by: owner-dfdl-wg@ggf.org 08/26/2005 06:26 PM To dfdl-wg@gridforum.org cc Subject [dfdl-wg] Draft document just under the wire for "official" commentary at GGF15 See http://forge.gridforum.org/docman2/ViewCategory.php?group_id=113&category_id=803&language_id=1&sort0=ddate&dir0=1 The document is "DFDL Proposal" and is posted in word and pdf formats. If you use the above URL it should be the top 2 documents on your display. We made the official deadline which means I can really needle people to study this document and comment on it on or before GGF15. A couple of notes: My group at IBM produced this draft. While we tried to fold in the viewpoints of others at IBM that we have been working with over the past few months, I cannot represent that this document reflects any overall consolidated "IBM opinion" on DFDL at this time. There hasn't been time for the rounds of IBM-internal review that would require. Rather this is my group's take on things. It reflects our best shot at how to combine the concepts of the OMG TD model and its attributes with the rest of the DFDL concepts. We updated the scoping proposal to fix some ambiguities left over from the F2F last may, and there's a section on layering which only starts to tell the story about this powerful capability, but is a good start at it. There's a middle section which just gets started at the agenda of explaining all the subtlety of exactly how delimiting and tagging work, and how lengths and positions are determined and so forth. You'll see lots of TBDs and rationale discussion in here still. My goal is that by or at GGF15 we resolve many of these so these rationale blocks can move down into the appendices or into separate documents, allowing us to focus on the meat of specifying the core behavior more thoroughly. In the appendix which contains the rep-properties detail you'll see lots of conflicts. E.g., we have byteOrder=bigEndian/littleEndian AND we have bigEndian=true/false. This is intentional and is the remnants of joining forces with the OMG Type-descriptor model. We need to decide on these conflicts i.e., for each one, which way do we want to go. There are quite a few such conflicts to be resolved. Our prototype implementation does not implement exactly what is described in this draft, though it is quite close. The differences are fairly insignificant. I recommend grabbing the MSWord version, and inserting lots of comment blocks as you read it using the comments feature. It is a big document though (50 pages), and different parts of it are more accessible than others, so do what you will. Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA
participants (3)
-
Jim Myers -
Mike Beckerle -
Robert E. McGrath