May 2005 - dfdl-wg - lists.ogf.org

uploaded to our gridforge page
by Mike Beckerle 22 Jun '05

22 Jun '05

I've uploaded notes and slides from the F2F, and as promised a zip of the examples we walked through from the Ascl (now IBM) prototype my group is working on. In this zip is testCase.xsd, which is the schema of the test-case files that we're using. These are a common format that we could all share for tests of a variety of implementations. http://forge.gridforum.org /projects/dfdl-wg/document/F2F_2005_05_Examples_and_XSDs/en/1. is the URL for the zip file. Sorry for the delay in getting this all up on gridforge. Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA

2 2

Hello everybody!
by Yi Zhu[MSc] 08 Jun '05

08 Jun '05

Hi, My name is Yi Zhu. I am a MSc student of EPCC, majoring in High Performance Computing. I am here because my final project is about DFDL (I am sorry for that as the project has just begun, what exactly will be implemented has not been decided), and I believe this is a interesting, challenging and promising field. However, I am a real beginer in DFDL, so I need all your help. Thanks ever so much! Regards, Yi

2 4

DFDL Scoping proposal document
by Mike Beckerle 27 May '05

27 May '05

At the F2F we discussed scoping of DFDL annotation properties. This document summarizes the proposal that emerged from the discussion. https://forge.gridforum.org /projects/dfdl-wg/document/DFDL_Scoping_Proposal_v001/en/1. Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA

2 1

Fw: TAG opinion on XML Binary Format
by Mike Beckerle 25 May '05

25 May '05

Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA ----- Forwarded by Mike Beckerle/Worcester/IBM on 05/24/2005 01:44 PM ----- ed.rice(a)hp.com 05/24/2005 01:26 PM To www-tag(a)w3.org, public-xml-binary(a)w3.org cc Subject TAG opinion on XML Binary Format TAG opinion on XML Binary Format The TAG has reviewed in detail the documents [1,2,3,4] prepared by the XBC workgroup [5]. While we very much appreciate the significant progress that these notes represent, the TAG believes that more detailed analysis is needed before a W3C Binary XML Recommendation is sufficiently justified. We are taking no position at this time as to whether Binary XML will prove to be warranted, as there seem to be good arguments on both sides of that question. Rather, we are suggesting that further careful analysis is needed before the W3C commits to a direction. The TAG believes there are disadvantages as well as potential advantages that will result from even a well crafted Binary XML Recommendation. The advantages are clear: a successful binary format is likely to provide speed gains or size reductions, at least for certain use cases. The drawbacks are likely to include reduced interoperability with XML 1.0 and XML 1.1 software, and an inability to leverage the benefits of text-based formats. These are important concerns. Quoting from the Web Architecture document[6]: "The trade-offs between binary and textual data formats are complex and application- dependent. Binary formats can be substantially more compact, particularly for complex pointer-rich data structures. Also, they can be consumed more rapidly by agents in those cases where they can be loaded into memory and used with little or no conversion. Note, however, that such cases are relatively uncommon as such direct use may open the door to security issues that can only practically be addressed by examining every aspect of the data structure in detail. "Textual formats are usually more portable and interoperable. Textual formats also have the considerable advantage that they can be directly read by human beings (and understood, given sufficient documentation). This can simplify the tasks of creating and maintaining software, and allow the direct intervention of humans in the processing chain without recourse to tools more complex than the ubiquitous text editor. Finally, it simplifies the necessary human task of learning about new data formats; this is called the "view source" effect." We therefore believe that the benefits of a binary XML must be predictable and compelling in order to justify development of a Recommendation. In particular, we suggest that a quantitative analysis is necessary. For at least a few key use cases, concrete targets should be set for the size and/or speed gains that would be needed to justify the disruption introduced by a new format. For example, a target might be that "in typical web services scenarios, median speed gains on the order of 3x in combined parsing and deserialization are deemed sufficient to justify a new format." We further suggest that representative binary technologies be benchmarked and analyzed to a sufficient degree that such speed or size improvements can be reasonably reliably predicted before we commit to a Recommendation. No doubt, any given set of goals or benchmarks will suffer from some degree of imprecision, but if the gains are sufficiently compelling to justify a new format, then they should be relatively easy to demonstrate. In short, actual measurements should be a prerequisite to preparing a Recommendation. In doing such measurements, we believe it is essential that comparisons be done to the best possible text-based XML 1.x implementations, which are not necessarily those that are most widely deployed. Stated differently: if XML 1.x is inherently capable of meeting the needs of users, then our efforts should go into tuning our XML implementations, not designing new formats. Benchmark environments should be as representative as possible of fully optimized implementations, not just of the XML parser, but of the surrounding application or middleware stack. We note that different application-level optimizations may be necessary to maximize the performance of the Binary or text cases respectively. Care should especially be taken to ensure that the performance of particular APIs such as DOM or SAX does not obscure the performance possible with either option (e.g. both SAX and DOM can easily result in high overhead string conversions when UTF-8 is used.) The TAG would also appreciate clarification as to how many formats are likely to be included in a Recommendation; it's not clear whether the proposal is for one binary xml format for all cases, or if multiple formats are to be endorsed. The use of multiple formats is likely to further reduce interoperability. We feel that introduction of a binary format would be an important development for those who might benefit from its size or speed, but also for those who might be impacted by its impact on interoperability and perspicuity. Therefore, in order to justify a potential new format, the TAG would like to see the above issues addressed. As stated above, we make no prediction as to whether such an analysis will ultimately confirm the need for Binary XML; if it does, we will be glad to support development of a Recommendation at the W3C. [1] http://www.w3.org/TR/xbc-use-cases/ <http://www.w3.org/TR/xbc-use-cases/> [2] http://www.w3.org/TR/xbc-properties/ <http://www.w3.org/TR/xbc-properties/> [3] http://www.w3.org/TR/xbc-measurement/ <http://www.w3.org/TR/xbc-measurement/> [4] http://www.w3.org/TR/xbc-characterization/ <http://www.w3.org/TR/xbc-characterization/> [5] http://www.w3.org/XML/Binary/ <http://www.w3.org/XML/Binary/> [6] http://www.w3.org/TR/webarch/#binary <http://www.w3.org/TR/webarch/#binary>

2 1

notes from 2005-05-11 F2F Day 1
by Mike Beckerle 12 May '05

12 May '05

Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA

1 0

only a test
by Mike Beckerle 11 May '05

11 May '05

please ignore this message Mike Beckerle Architect, Scalable Computing IBM Software Group Information Integration Solutions Westborough, MA

1 0

Draft Agenda for F2F
by mike.beckerle＠ascentialsoftware.com 06 May '05

06 May '05

My ideas for draft agenda. This ppt should be openable in open-office and MS Office. Please put suggestions for reordering, topics you'd like to add, topics you think are higher/lower priority, and so forth and send back to me. I'll attempt to coalese into a unified "next spin" on the agenda and I'll repost it at that time. ...mikeb

2 1