RE: use cases: binary XML for scientifc computing

I was kind of hoping for 3 but for the parser to take care of it.  That
is, for Microsoft, IBM, Sun or whoever to do the grunt work, based on
complying with some spec, rather than repeating the programming task N
times at N places that use the data.  I think that's a little different
from any of your options, isn't it?

  _____  

From: Stephen D. Williams [mailto:sdw@lig.net] 
Sent: Monday, November 22, 2004 8:38 PM
To: Cutler, Roger (RogerCutler)
Cc: mike.beckerle@ascentialsoftware.com; aslom@cs.indiana.edu;
whoschek@lbl.gov; xml-dev@lists.xml.org; public-xml-binary@w3.org;
kchiu@cs.binghamton.edu; mgovinda@cs.binghamton.edu
Subject: Re: use cases: binary XML for scientifc computing


This is the whole problem of binary scalars: there are several existing
formats and more are obviously possible in the future.
The arguments related to binary scalars include:


1.	It's an open-ended mess, just use character representation 
2.	Choosing one standard method ("network byte order") is the way
to go 
3.	Choose the best 'local' method which is great for homogeneity
and 'reader makes right' doable by dissimilar communicators. 
4.	A new custom binary format is appropriate to the application
(such as Oracle's internal Number format which has interesting
properties).
	

Option 3 seems to have the most backing for those who are willing to
work past option 1.  This would require that a full implementation of a
format, or a layer above it, be able to convert from any "generally
accepted" scalar to the local version.  Converting to any "generally
accepted" format could be optional, but useful.

This problem of one application, directly or indirectly, choosing a
particular format that differs from the reading application also occurs
at the character encoding level.  The solution of being able to convert
at the receiver and optionally at the sender seems reasonable.  

The remaining problem then is the ability to integrate newly invented
scalar representations, but this seems to be a minor issue currently.

sdw

Cutler, Roger (RogerCutler) wrote: 

	Seems to me that DFDL fits the floating point data usage case I
contributed very well -- except maybe for the desire for somebody else
to handle the floating point conversion issues between platforms.  That
is, "just get on with it" when your IO libraries expect different float
structures than that of the source of the data can be a bit painful.  My
contacts really don't writing that low level code over and over, with of
course the potential for getting it a bit wrong somehow each time.
	 
	-----Original Message-----
	From: mike.beckerle@ascentialsoftware.com
[mailto:mike.beckerle@ascentialsoftware.com] 
	Sent: Monday, November 22, 2004 5:31 PM
	To: Cutler, Roger (RogerCutler); aslom@cs.indiana.edu;
sdw@lig.net
	Cc: whoschek@lbl.gov; xml-dev@lists.xml.org;
public-xml-binary@w3.org; kchiu@cs.binghamton.edu;
mgovinda@cs.binghamton.edu
	Subject: RE: use cases: binary XML for scientifc computing
	
	
	I do believe that GGF DFDL is relevant to the discussion here.
https://forge.gridforum.org/projects/dfdl-wg/ is the site, and 
	
https://forge.gridforum.org/docman2/ViewProperties.php?group_id=113&cate
gory_id=803&document_content_id=2973 (or http://tinyurl.com/435j7 in
case email clobbered the long URL) is the most recent presentation.
Around slide 7 is where you'll find content.
	 
	Here's a snippet to give you the "DFDL" idea:
	

...


-- 
swilliams@hpti.com http://www.hpti.com Per: sdw@lig.net http://sdw.st
Stephen D. Williams 703-724-0118W 703-995-0407Fax 20147-4622 AIM: sdw