headers
David Ryan | 1 Dec 2004 03:48
Picon

Re: Non-XML binary formats.


Paul Thorpe wrote:

>>I've come from the direction of CORBA and other Remote Procedure Call
>>architectures.  What I was looking for was a way of doing strong data
>>type agreement between two systems that have not previously had any
>>contact or been developed by the same parties.  This requires that the
>>two systems are able to negotiate if they have the same data type
>>formats dynamically; ensuring that their encodings also match.  This
>>allows partial schema matching between two systems.  It requires that
>>the schemas act more as dictionaries instead of schemas, or I believe
>>the term in ASN.1 is modules.  It allows an individual application to
>>build it's own vocabulary which meets its own needs, and then allows a
>>client to discover if there is a match between its own vocabulary and
>>the server's dynamically.  Argot was my solution for that problem.  If
>>ASN.1 does allow such matching, I'd be interested in what part of
>>specifications show this.
>>    
>>
>
>ASN.1 supports this capability via what we call Extensible Information
>Object Set.  You can constrain a particular portion of a message (an
>Envelope message perhaps with some "hole" for open content) using an
>Information Object Set (to indicate what that "hole" should contain).
>That Information Object Set can be dynamically changed (by addition or
>deletion) at runtime to alter the nature of the content permitted.
>
>  
>
I went back to the standards page and had a closer look at the X.681
(Continue reading)

Permalink | Reply | 1 comment |
headers
Paul Thorpe | 1 Dec 2004 20:15
Favicon

Re: Non-XML binary formats.


On Wed, 1 Dec 2004, David Ryan wrote:

> Paul Thorpe wrote:
>
> >>I've come from the direction of CORBA and other Remote Procedure Call
> >>architectures.  What I was looking for was a way of doing strong data
> >>type agreement between two systems that have not previously had any
> >>contact or been developed by the same parties.  This requires that the
> >>two systems are able to negotiate if they have the same data type
> >>formats dynamically; ensuring that their encodings also match.  This
> >>allows partial schema matching between two systems.  It requires that
> >>the schemas act more as dictionaries instead of schemas, or I believe
> >>the term in ASN.1 is modules.  It allows an individual application to
> >>build it's own vocabulary which meets its own needs, and then allows a
> >>client to discover if there is a match between its own vocabulary and
> >>the server's dynamically.  Argot was my solution for that problem.  If
> >>ASN.1 does allow such matching, I'd be interested in what part of
> >>specifications show this.
> >>
> >>
> >
> >ASN.1 supports this capability via what we call Extensible Information
> >Object Set.  You can constrain a particular portion of a message (an
> >Envelope message perhaps with some "hole" for open content) using an
> >Information Object Set (to indicate what that "hole" should contain).
> >That Information Object Set can be dynamically changed (by addition or
> >deletion) at runtime to alter the nature of the content permitted.
> >
> >
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robin Berjon | 1 Dec 2004 21:48
Picon

Re: Non-XML binary formats.


David Ryan wrote:
> But I'm 
> surprised there is so little choice around for this problem; especially 
> given that the problem of developing and agreeing upon a data format or 
> schema is so fundamental.  Just to reiterate my question in a slightly 
> different way.  Is there no other binary format around, that is not 
> ASN.1 and is not a simple binary formated XML(ie A binary encoding that 
> is flexible and that has schema properties to describe the format of the 
> encoding)?

What do you mean by "a simple binary formated XML"? There are quite a 
few binary XML formats out there that do more than just replacing tags 
with binary tokens. Some use schema information to encore XML 
information in binary form.

--

-- 
Robin Berjon
Permalink | Reply | 2 comments |
headers
David Ryan | 2 Dec 2004 01:08
Picon

Re: Non-XML binary formats.


Robin Berjon wrote:

>
> David Ryan wrote:
>
>> But I'm surprised there is so little choice around for this problem; 
>> especially given that the problem of developing and agreeing upon a 
>> data format or schema is so fundamental.  Just to reiterate my 
>> question in a slightly different way.  Is there no other binary 
>> format around, that is not ASN.1 and is not a simple binary formated 
>> XML(ie A binary encoding that is flexible and that has schema 
>> properties to describe the format of the encoding)?
>
>
> What do you mean by "a simple binary formated XML"? There are quite a 
> few binary XML formats out there that do more than just replacing tags 
> with binary tokens. Some use schema information to encore XML 
> information in binary form.
>
You are correct that with "simple binary formated XML", I was referring 
to are those that just perform tokenisation of XML and don't use an XML 
Schema.  Can you point me to those XML binary formats that use XML 
Schema in the encoding process? This might have some relevance to Argot.

Originally I expected to find some formats other than ASN.1 that I could 
investigate in relation to my own work with Argot.  I specifically asked 
for non-XML binary formats, because I was interested to see what other 
work had been done that wasn't tied to XML Schema or XML directly.  
Specifically, I was looking for other ways of defining binary
(Continue reading)

Permalink | Reply | 1 comment |
headers
Robin Berjon | 1 Dec 2004 23:01
Picon

Re: Non-XML binary formats.


Bob Wyman wrote:
> David Ryan wrote:
>>I'm guessing this debate has been going on for a while already. :)
> 
> 	Yes, about 20 years at this point. It started as SGML vs. ASN.1 back
> when most of today's coders were still in kindergarten.

The real problem here is in the "vs". Sometimes there are very good 
reasons to use text, and sometimes there are very good reasons to use 
binary. I'm still curious to find out why SGML-B never took off, but 
unfortunately have not been able to get an answer out of anyone that was 
there.

>>I have briefly looked at ASN.1 in the past and found it wasn't
>>what I was looking for.
> 
> 	Yes. Most such statements start with something like "briefly
> looked." The reality is that ASN.1 has always been able to do all that XML
> could do and it has been doing it for 20 years.

That's simply not an argument that flies. We put people on the moon with 
Cobol and Fortran, yet we tend to use different languages today and 
there probably are reasons for that. I'm not saying that ASN.1 is the 
Cobol of data frameworks, but simply that "already could do for n years" 
is a non-argument.

> The problem is that people
> typically look at it "briefly," get overwhelmed by what they consider to be
> complexity or a hard to read specification and then decide to do something
(Continue reading)

Permalink | Reply | 5 comments |
headers
Robin Berjon | 1 Dec 2004 23:14
Picon

Re: Non-XML binary formats.


David Ryan wrote:
> Sorry if I've taken this mailing list off topic.

I don't think that your thread is off-topic, though some posts in it may be.

 > Having heard some of
 > the issues and reignited the old ASN.1 debate, I'd be interested know
 > what direction the XML Binary Characterisation working group are
 > currently heading?

We're almost done gathering use cases 
(http://www.w3.org/TR/xbc-use-cases/) and inferring properties that are 
useful in discussing binary XML problems 
(http://www.w3.org/TR/xbc-properties/). We've started documenting 
measurement methodologies to apply the latter to actual formats 
correctly, and are entering the part where we try to see if there's the 
potential for a solution that would address enough of the use cases, or 
characterization proper. Our final answer is to be produced next March, 
in the meantime feedback on the existing drafts is very much welcome.

--

-- 
Robin Berjon
Permalink | Reply | 0 comments |
headers
Paul Thorpe | 2 Dec 2004 05:46
Favicon

Re: Non-XML binary formats.


On Wed, 1 Dec 2004, Robin Berjon wrote:

>
> Bob Wyman wrote:
> > David Ryan wrote:
> >>I'm guessing this debate has been going on for a while already. :)
> >
> > 	Yes, about 20 years at this point. It started as SGML vs. ASN.1 back
> > when most of today's coders were still in kindergarten.
>
> The real problem here is in the "vs". Sometimes there are very good
> reasons to use text, and sometimes there are very good reasons to use
> binary. I'm still curious to find out why SGML-B never took off, but
> unfortunately have not been able to get an answer out of anyone that was
> there.
>
> >>I have briefly looked at ASN.1 in the past and found it wasn't
> >>what I was looking for.
> >
> > 	Yes. Most such statements start with something like "briefly
> > looked." The reality is that ASN.1 has always been able to do all that XML
> > could do and it has been doing it for 20 years.
>
> That's simply not an argument that flies. We put people on the moon with
> Cobol and Fortran, yet we tend to use different languages today and
> there probably are reasons for that. I'm not saying that ASN.1 is the
> Cobol of data frameworks, but simply that "already could do for n years"
> is a non-argument.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bob Wyman | 2 Dec 2004 11:12
Picon

RE: Non-XML binary formats.


Robin Berjon wrote:
> Your tone here makes me wonder...
	If there is some emotion in my tone it is rooted in the frustration
that comes from watching the glacial pace of the XBC process while knowing
that there are at least some of us that need to build systems TODAY that
have the efficiencies and advantages provided by binary formats. Had it not
been for the fact that all of the requirements that are so far identified by
the XBC group have been the subject of constant scrutiny, debate and
resolution for over 20 years, then I would be much more patient. However,
the simple fact is that the ASN.1 group has been dealing with all of these
issues for years and has produced a system that can address the vast
majority of the needs identified. 
	What the XBC process is doing is creating FUD (Fear Uncertainty and
Doubt) that prevents us from deploying standards-based binary solutions
today. Any proposal for a binary based system today is routinely rejected
not on technical grounds but rather with the statement that "We should wait
to see what W3C says." Thus, we are forced to accept higher bandwidth costs
then would otherwise be necessary, higher processing costs, etc. The glacial
pace of the XBC process is costing us money and preventing us from
satisfying user requirements for responsive, efficient systems. These costs
simply do not seem justified given that ASN.1 exists, is a standard, and
there are no recognized standard alternatives that address the same range of
requirements that ASN.1 does. 
	We have already been forced to accept the cost of waiting for and
now dealing with XML Schema -- even though its mapping to a subset of ASN.1
has shown that the effort contributed little of new value -- other than a
ridiculously verbose and difficult to read syntax whose only redeeming
quality seems to be its blessing by the W3C. Now, we're being slowed down
again as the W3C insists once again that the industry can move no faster
(Continue reading)

Permalink | Reply | 3 comments |
headers
Don Brutzman | 2 Dec 2004 15:03

Re: Non-XML binary formats.


David Ryan wrote:
> [...]   Can you point me to those XML binary formats that use XML
> Schema in the encoding process? This might have some relevance to Argot.

We have an XML Schema-based Binary Compression (XSBC) library that uses
an XML schema as the determining document for how to compress a tagset.

http://www.movesinstitute.org/xmsf/xmsf.html#Projects-XSBC

Codebase is on SourceForge, I expect that Don McGregor and Alan Hudson
(cc:ed) will have an update there in the near future.

all the best, Don
--

-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       work +1.831.656.2149
               MOVES Institute, Monterey CA 93943-5000 USA  fax  +1.831.656.7599
Virtual worlds/underwater robots/X3D/XMSF     http://web.nps.navy.mil/~brutzman
Permalink | Reply | 0 comments |
headers
mike.beckerle | 3 Dec 2004 16:31

Clarifying DFDL vs. Binary XML (was RE: use cases: binary XML for scientifc computing)


I would also like to see use cases which clarify the differences between
binary-xml and DFDL so that we're not constantly revisiting that and we can
have a positive URL reference to some clarifying point that both Binary XML
and DFDL teams can depend on. To me the crux of the issue is that in the
DFDL/descriptive world, you have this problem of data format debugging,
i.e., what if the description is wrong? This is what you avoid with the
binary-XML/prescriptive approach, and it is very worth avoiding. This is why
I see the need for both and their overlap doesn't bother me.

To that end, here's some language revised from an earlier posting, which
makes this point about presecriptive vs. descriptive formats. You can adapt
it as you see fit.

Binary-XML is a prescriptive approach, that is, it specifies a universal
format that is used for data. Binary-XML shares this category with ASN.1 and
XDR, but leverages the popularity of the XML family of standards. The DFDL
approach is descriptive. That is, the data has some format. You describe in
DFDL the format the data is in. Use-cases where this approach is preferable
include high-performance programs which often want to arrange for data
structures to be aligned and directly mappable into memory layouts or
randomly accessible on disk. DFDL allows data to meet these requirements
while still being universally described for interchange with other programs.
Other important DFDL use cases include the broad array of legacy data
formats. DFDL also leverages XML technologies for describing the logical
structure of the data, but adds the ability to describe a different physical
realization. 

Pros and Cons: The Binary-XML prescriptive approach is preferable for new
programs which simply need the improved performance and density of a binary
(Continue reading)

Permalink | Reply | 752 comments |

Gmane