- dfdl-wg - lists.ogf.org

Fw: [dfdl-wg] Microsoft Biztalk Flat File Extensions
by Suman Kalia 28 Jan '05

28 Jan '05

Mike -- This seems quite similar to the proposal I submited based on Type Descriptor. They have a schema for the physical representation and the instances of which (eg. recordInfo, fieldInfo etc) appear as annotations on schema elements , attributes etc. Suman Kalia IBM Toronto Lab WebSphere Business Integration Application Connectivity Tools Tel : 905-413-3923 T/L 969-3923 Fax : 905-413-4850 Internet ID : kalia(a)ca.ibm.com ----- Forwarded by Suman Kalia/Toronto/IBM on 01/28/2005 09:20 AM ----- mike.beckerle(a)ascentialsoftware.com Sent by: owner-dfdl-wg(a)ggf.org 01/28/2005 04:36 AM To dfdl-wg(a)gridforum.org cc Subject [dfdl-wg] Microsoft Biztalk Flat File Extensions Microsoft has a completely proprietary but otherwise DFDL-like thing in its bag of tricks too: see http://www.winterdom.com/dev/bts/BTSFFSchemaTut2.html

1 0

Microsoft Biztalk Flat File Extensions
by mike.beckerle＠ascentialsoftware.com 28 Jan '05

28 Jan '05

Microsoft has a completely proprietary but otherwise DFDL-like thing in its bag of tricks too: see http://www.winterdom.com/dev/bts/BTSFFSchemaTut2.html <http://www.winterdom.com/dev/bts/BTSFFSchemaTut2.html>

1 0

new specs from w3c
by mike.beckerle＠ascentialsoftware.com 26 Jan '05

26 Jan '05

This info FYI. We will be asked to position DFDL vis a vis XML optimized via XOP for example. I don't think this changes anything. These are again "prescriptive" data representation schemes. DFDL is descriptive. But it is addressing some of the "XML is too bloated and slow" concerns bit by bit. Also, I think XOP is only efficient if used to package large binary objects like images and such. If you had data with lots of small fields in it then XOP doesn't help. ...mikeb cg20W3C Specs for "Faster, Efficient" Web Services Section: 04. Application Development and Platforms The World Wide Web Consortium (W3C) yesterday issued three recommended web services specifications, designed to efficiently package and transmit binary data included in, or referenced in, SOAP 1.2. The group has released XML-binary Optimized Packaging (XOP), SOAP Message Transmission Optimization Mechanism (MTOM) and Resource Representation SOAP Header Block (RRSHB). In a statement, the W3C said the specifications means web services "just became faster and more usable." Michael Curry Ascential SOA Product Marketing O: 508-599-7157 M: 508-904-7384 <http://www.ascential.com/> http://www.ascential.com

1 0

RE: [dfdl-wg] F2F Meeting Status Report
by mike.beckerle＠ascentialsoftware.com 11 Jan '05

11 Jan '05

I posted this revised set of F2F status notes on gridforge. There will probably be some reason why somebody can't see it. So please try to get to it. Title is ggf-dfdl-wg-2004-12-06-meeting-summary002 and there are .doc and .pdf variants. ...mikeb _____ From: Myers, James D [mailto:jim.myers@pnl.gov] Sent: Tuesday, December 14, 2004 10:25 AM To: dfdl-wg(a)gridforum.org Subject: RE: [dfdl-wg] F2F Meeting Status Report Some suggestions/comments, mostly to capture info from the times we split into parallel discussions (paramterized types versus the TD model, discussion of reader,writer,filter, function at the end). Fixed a couple typos as well with everything tracked as changes. Jim -----Original Message----- From: owner-dfdl-wg(a)ggf.org [mailto:owner-dfdl-wg@ggf.org] On Behalf Of mike.beckerle(a)ascentialsoftware.com Sent: Wednesday, December 08, 2004 4:49 PM To: dfdl-wg(a)gridforum.org Subject: [dfdl-wg] F2F Meeting Status Report Attached is my status on this F2F. This ".doc" file seems to work in both MS Word and OpenOffice, though the heading numbers do change somewhat. Comments, feedback, things I forgot are all welcome. I'll post to grid forge once people affirm that I have everything captured, or enough anyway. ...mikeb

1 0

Conf. call Wednesday 2005-01-05 ??
by mike.beckerle＠ascentialsoftware.com 04 Jan '05

04 Jan '05

My calendar has us scheduled for a call this week. Shall we do it?

1 0

Call Today?
by mike.beckerle＠ascentialsoftware.com 22 Dec '04

22 Dec '04

Are we having a DFDL call today? We're scheduled for it, but given the upcoming holiday I wonder if anyone will be on the call.

2 1

RE: [dfdl-wg] F2F Meeting Status Report
by Myers, James D 14 Dec '04

14 Dec '04

Some suggestions/comments, mostly to capture info from the times we split into parallel discussions (paramterized types versus the TD model, discussion of reader,writer,filter, function at the end). Fixed a couple typos as well with everything tracked as changes. Jim -----Original Message----- From: owner-dfdl-wg(a)ggf.org [mailto:owner-dfdl-wg@ggf.org] On Behalf Of mike.beckerle(a)ascentialsoftware.com Sent: Wednesday, December 08, 2004 4:49 PM To: dfdl-wg(a)gridforum.org Subject: [dfdl-wg] F2F Meeting Status Report Attached is my status on this F2F. This ".doc" file seems to work in both MS Word and OpenOffice, though the heading numbers do change somewhat. Comments, feedback, things I forgot are all welcome. I'll post to grid forge once people affirm that I have everything captured, or enough anyway. ...mikeb

1 0

RE: [dfdl-wg] Plumbing document
by mike.beckerle＠ascentialsoftware.com 09 Dec '04

09 Dec '04

Comments on the document. It would be most helpful if all sections were numbered so that comments can be made specific, but let me do it this way for now: Section 1.Function.Use About "runtimeOccurs". I think the prefix "runtime" is part of recognizing that there are static parameters and dynamic parameters. We think of byteOrder as something static or usually static, though in reality, it can vary based on an indicator found in the file, witness the UTF-16 character set which can have a byte-order-mark at the beginning to indicate whether it is really UTF-16BE or UTF-16LE. The question is whether the separation of static and dynamic as the usual usage pattern for each parameter is tight enough that we feel comfortable putting something like "runtime..." in front of the name. In fact the parameters runtimeOccurs and runtimeValue probably should be renamed to occurs and value to reflect that they can be either static or dynamic just like byteOrder can be. I like better the proposal you have in section 3.Parameter Properties where you have two states for each parameter, dynamic static, and scoped not-scoped. I'd rather not encode the status of the parameter with respect to these two states in its name. Section 2 I want to noodle with the mathematical semantics of reader/writer/filter a bit here. I think this is all not crisp enough yet. In particular, I want to break streams up into sets of values, and separate out keeping track of cursor position. This will let us make absolutely clear what is going on with what I called "length protocols" in previous emails. So I would redefine reader to take in an input (set of values with positions), a cursor position, and to compute a value, and a new cursor position, but not to have any side-effects, i.e., a pure function. A writer takes a stream (set of values with positions), a current position, and a value, and produces a stream (with more members in the set) and a new position. I need to work on this more and present it back to you all. Section 3 The scoping scheme you describe here makes sense to me. However, I worry about order sensitivity. Suppose I moved the top level bigEndian annotation to a position textually after the definition of xType. Would xType now be without any annotations? Or does order not matter? Order sensitivity of this kind is consistent with programming-language semantics which generally considers both order and nesting level together when considering scope of a declaration. I believe we will want the ability to do both: 1) introduction of global defaults for rep parameters 2) introduction of reusable complexType definitions which *take no position* on rep parameters such that their use points inherit local control over rep. To do this in your example I'd have to be able to get the xType's definition out of the scope of the global declarations somehow. Just switching the order around would do it if we're comfortable with that. > -----Original Message----- > From: Martin Westhead [mailto:martinwesthead@yahoo.co.uk] > Sent: Wednesday, December 08, 2004 3:16 PM > To: dfdl-wg(a)gridforum.org > Subject: [dfdl-wg] Plumbing document > > Hi Folks, > > Sorry you didn't get a round up Susan, I'm afraid we were not > prepared for it. I was on the call this morning ready to > summarise events but I was the only one on. > > Based on discussions, yesterday afternoon I have drawn up the > attached document. The starting point for this was stuff that > was agreed but I have tried to flesh it out and push the > ideas in various directions. > > I have tried to suggest a what would be required to define > and use each of our various operation elements. I have also > proposed a possible solution to the scoping problem. > > This document may not make much sense to those who were not > at the face to face and for that reason I do not propose to > put it on Grid Forge yet. It should provide some material for > our GGF13 submission. > > It would, of course be very useful if those at the F2F could > take a look and comment before our collective memories of > what we discussed fade. > > Thanks, > > Martin > > (Doc is in PDF because I'm not confident that OpenOffice -> > Word will preserve the diagrams. If anyone wants to make > detailed comments I'll send them a Word version too.) >

1 0

F2F Meeting Status Report
by mike.beckerle＠ascentialsoftware.com 08 Dec '04

08 Dec '04

Attached is my status on this F2F. This ".doc" file seems to work in both MS Word and OpenOffice, though the heading numbers do change somewhat. Comments, feedback, things I forgot are all welcome. I'll post to grid forge once people affirm that I have everything captured, or enough anyway. ...mikeb

1 0

Plumbing document
by Martin Westhead 08 Dec '04

08 Dec '04

Hi Folks, Sorry you didn't get a round up Susan, I'm afraid we were not prepared for it. I was on the call this morning ready to summarise events but I was the only one on. Based on discussions, yesterday afternoon I have drawn up the attached document. The starting point for this was stuff that was agreed but I have tried to flesh it out and push the ideas in various directions. I have tried to suggest a what would be required to define and use each of our various operation elements. I have also proposed a possible solution to the scoping problem. This document may not make much sense to those who were not at the face to face and for that reason I do not propose to put it on Grid Forge yet. It should provide some material for our GGF13 submission. It would, of course be very useful if those at the F2F could take a look and comment before our collective memories of what we discussed fade. Thanks, Martin (Doc is in PDF because I'm not confident that OpenOffice -> Word will preserve the diagrams. If anyone wants to make detailed comments I'll send them a Word version too.)

1 0