These are documents 3 and 4 of a set of 3 :). The documents are: - bundles - a reusable block of DFDL statements - Conversions - a proposal for the semantic details as to how conversions are chosen during the operation of a DFDL parser. These semantics include a description as to how the conversions can be extended. These documents round off the current set of proposals from the extensibility design team. The team has reasonable consensus on these documents, with the (relatively trivial) exception of bundles where there may be some outstanding issues. We believe that with these two documents there is enough material to support the necessary extensibility. However, we have not yet worked through enough examples of round tripping to understand whether that is sufficiently well covered and we are expecting that all the ideas in these documents will require refining by the group as a whole. I would like to discuss these two documents on Wednesday (if possible). Thanks, Martin
Sorry I missed the call this past week. Here are my comments and some in-line editing on the I actually think the primary reason to push this document forward is NOT extensibility, but because it is needed to clarify the basic semantics of DFDL. That is, it allows us to make very clear exactly what properties in the annotations are guiding the selection of which conversion functions. ...mikeb Mike Beckerle STSM, Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA 01581 voice and FAX 508-599-7148 home/mobile office 508-915-4767 "Westhead, Martin (Martin)" <westhead@avaya.com> Sent by: owner-dfdl-wg@ggf.org 01/23/2006 04:58 PM To <dfdl-wg@ggf.org> cc Subject [dfdl-wg] More documents These are documents 3 and 4 of a set of 3 :). The documents are: - bundles ? a reusable block of DFDL statements - Conversions ? a proposal for the semantic details as to how conversions are chosen during the operation of a DFDL parser. These semantics include a description as to how the conversions can be extended. These documents round off the current set of proposals from the extensibility design team. The team has reasonable consensus on these documents, with the (relatively trivial) exception of bundles where there may be some outstanding issues. We believe that with these two documents there is enough material to support the necessary extensibility. However, we have not yet worked through enough examples of round tripping to understand whether that is sufficiently well covered and we are expecting that all the ideas in these documents will require refining by the group as a whole. I would like to discuss these two documents on Wednesday (if possible). Thanks, Martin[attachment "DFDL_Conversions_4.doc" deleted by Mike Beckerle/Worcester/IBM] [attachment "DFDL_Bundles_2.doc" deleted by Mike Beckerle/Worcester/IBM]
Oh yeah, forgot the attachment. Mike Beckerle STSM, Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA 01581 voice and FAX 508-599-7148 home/mobile office 508-915-4767 Mike Beckerle/Worcester/IBM@IBMUS Sent by: owner-dfdl-wg@ggf.org 01/27/2006 07:50 PM To "Westhead, Martin (Martin)" <westhead@avaya.com> cc dfdl-wg@ggf.org, owner-dfdl-wg@ggf.org Subject Re: [dfdl-wg] More documents Sorry I missed the call this past week. Here are my comments and some in-line editing on the I actually think the primary reason to push this document forward is NOT extensibility, but because it is needed to clarify the basic semantics of DFDL. That is, it allows us to make very clear exactly what properties in the annotations are guiding the selection of which conversion functions. ...mikeb Mike Beckerle STSM, Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA 01581 voice and FAX 508-599-7148 home/mobile office 508-915-4767 "Westhead, Martin (Martin)" <westhead@avaya.com> Sent by: owner-dfdl-wg@ggf.org 01/23/2006 04:58 PM To <dfdl-wg@ggf.org> cc Subject [dfdl-wg] More documents These are documents 3 and 4 of a set of 3 :). The documents are: - bundles ? a reusable block of DFDL statements - Conversions ? a proposal for the semantic details as to how conversions are chosen during the operation of a DFDL parser. These semantics include a description as to how the conversions can be extended. These documents round off the current set of proposals from the extensibility design team. The team has reasonable consensus on these documents, with the (relatively trivial) exception of bundles where there may be some outstanding issues. We believe that with these two documents there is enough material to support the necessary extensibility. However, we have not yet worked through enough examples of round tripping to understand whether that is sufficiently well covered and we are expecting that all the ideas in these documents will require refining by the group as a whole. I would like to discuss these two documents on Wednesday (if possible). Thanks, Martin[attachment "DFDL_Conversions_4.doc" deleted by Mike Beckerle/Worcester/IBM] [attachment "DFDL_Bundles_2.doc" deleted by Mike Beckerle/Worcester/IBM]
I've read the Conversions document and to be honest I had a great deal of trouble trying to work out what was going on. I'd like to see an example of a DFDL schema that models a text stream that contains (say) a complex type with string, integer and decimal children, with DFDL properties used to handle the implicit conversions from text to logical data type. Then I'd like to see the same DFDL schema but with equivalent conversions explicitly declared and used instead of the DFDL properties. Regards, Steve Steve Hanson WebSphere Message Brokers, IBM Hursley, England Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 Mike Beckerle <beckerle@us.ibm. com> To Sent by: Mike Beckerle <beckerle@us.ibm.com> owner-dfdl-wg@ggf cc .org dfdl-wg@ggf.org, owner-dfdl-wg@ggf.org, "Westhead, Martin (Martin)" 28/01/2006 04:17 <westhead@avaya.com> Subject Re: [dfdl-wg] More documents Oh yeah, forgot the attachment. Mike Beckerle STSM, Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA 01581 voice and FAX 508-599-7148 home/mobile office 508-915-4767 Mike Beckerle/Worcester/IBM@IBMUS Sent by: owner-dfdl-wg@ggf.org To "Westhead, Martin (Martin)" 01/27/2006 07:50 PM <westhead@avaya.com> cc dfdl-wg@ggf.org, owner-dfdl-wg@ggf.org Subject Re: [dfdl-wg] More documents Sorry I missed the call this past week. Here are my comments and some in-line editing on the I actually think the primary reason to push this document forward is NOT extensibility, but because it is needed to clarify the basic semantics of DFDL. That is, it allows us to make very clear exactly what properties in the annotations are guiding the selection of which conversion functions. ...mikeb Mike Beckerle STSM, Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA 01581 voice and FAX 508-599-7148 home/mobile office 508-915-4767 "Westhead, Martin (Martin)" <westhead@avaya.com> Sent by: owner-dfdl-wg@ggf.org To <dfdl-wg@ggf 01/23/2006 04:58 PM .org> cc Subject [dfdl-wg] More documents These are documents 3 and 4 of a set of 3 :). The documents are: - bundles – a reusable block of DFDL statements - Conversions – a proposal for the semantic details as to how conversions are chosen during the operation of a DFDL parser. These semantics include a description as to how the conversions can be extended. These documents round off the current set of proposals from the extensibility design team. The team has reasonable consensus on these documents, with the (relatively trivial) exception of bundles where there may be some outstanding issues. We believe that with these two documents there is enough material to support the necessary extensibility. However, we have not yet worked through enough examples of round tripping to understand whether that is sufficiently well covered and we are expecting that all the ideas in these documents will require refining by the group as a whole. I would like to discuss these two documents on Wednesday (if possible). Thanks, Martin[attachment "DFDL_Conversions_4.doc" deleted by Mike Beckerle/Worcester/IBM] [attachment "DFDL_Bundles_2.doc" deleted by Mike Beckerle/Worcester/IBM] (See attached file: DFDL_Conversions_4.doc)
Comments on 2 of Mike's comments (in the document he sent Friday). MJB 1
I don't see how this proposal can enable creation of "arrays" as an extension. We had previously put off multi-dimensional arrays by suggesting they might fall out of the extensions proposal, but I can't see how to do that from this proposal.
That's ok. Maybe arrays don't fall out of the extensibility stuff.
On the other hand, maybe somebody already has an idea for how they could but it just isn't explained here.
I think this is a foundation to build on. IMO, there are 2 problems to be addressed for Arrays: 1) what XML structure should be used 2) how to get data from a variety of stored representations I think we want to let the user do whatever they want for #1. For #2, I think we can use a stack of conversions. Perhaps the "bottom" would be a big BLOB, or 1D array of elements, with another layer that defines which of the elements/bytes are element (x, y, z). I _think_ this could work, but I reserve the right to be wrong when someone tells me why this can't work! MJB6 (WRT a guard XPATH, p. 6)
I'm a bit dissatisfied with this. For realistic conversions I foresee that these predicates are going to be gargantuan sets of things that are combinations of presence or absence of all sorts of rep-property settings, including tests on whether the property's value is literal or is itself a run-time-value. E.g., bytes to Int for binary representations needs to know that the rep-type is binary and that byteOrder is specified to have a value.
I'd prefer that each conversion can have a black-box predicate which can examine the current static context.
Sure, I'd like to see the option for either WB or BB computations for these guards. Since XML is essentially unreadable to me, I haven't been concerned by constructs that might be realy, really, unreadable.
participants (4)
-
Mike Beckerle -
Robert E. McGrath -
Steve Hanson -
Westhead, Martin (Martin)