Re: Comments on XBC Use Cases

This is exactly why the lifecycle issue is a red herring, in my 
opinion.  If you can express a document in XML 1.x text-encoding, the 
fact that you usually process it as a faster and/or smaller binary 
format doesn't preclude you from archiving it in a text-encoded form.

If W3C doesn't work on "binary XML" and some other group takes up a 
similar challenge, that group may innovate away from and indepedent of 
XML to an extent that it becomes a bother to convert to and from 
text-encoded XML.  For applications that need increased efficiency, the 
objection that a long term archival format is needed could be considered 
an argument for "binary XML" since it would be closely associated with 
text-encoded XML.

sdw

Bullard, Claude L (Len) wrote:

>Yes.  Same here.  I reprocessed ATOS SGML docs 
>into HTML and XML in very short order in '95/96.  As a lifecycle 
>enhancer, markup is quite effective (putting aside the 
>problems of semantic associations to GIs).
>
>Human to human communications, and communications that 
>may require inspection to verify or validate benefit 
>greatly from text representations. Cut and paste 
>operations, debugging by hand, etc., are better 
>in plain text. My experience is (from VRML), that 
>one keeps the document in that format until satisfied, 
>then compiles it/binarizes/zips.
>
>I don't think of a binary as a replacement for XML. 
>I think of it as an alternative encoding for those 
>cases where performance or size do matter.
>
>That is why X3D has three encodings, all with equivalent 
>information properties, and each optimized for some 
>quality the designers thought critical.  I fought 
>the idea of three encodings, but so far, we don't 
>have any evidence that they have created lifecycle 
>problems (just implementation costs).  The problems 
>that are evident are usually in the object model 
>and the programming interface.  So one might ask 
>if the binary introduces processor semantics problems, 
>but I doubt that is the case.  It is a case for 
>better performance trading on reuse and access.
>
>len
>
>
>From: Norman Walsh [mailto:Norman.Walsh@Sun.COM]
>
>I think you're asking "how long does a document have to exist before
>it becomes important to be able to read it independent of the systems
>that originally produced it?"
>
>| What about short lifecycle documents?
>|
>| Lifecycle is in the eye of the operator.  While the lifecycle 
>| property is a compelling property of XML, it is not of 
>| necessity a constraining property of all of its applications 
>| in time and space.  Forgetting is as important as remembering.
>
>That's a good point. The long-term understandability of an ephemeral
>message is irrelevant. Though there's nothing about understandability
>that prevents one from forgetting :-)
>
>To be a little more clear, I wasn't trying to assert that it be a
>"constraining property of all of its applications" only that in the
>"electronic document" use case, it was a property of very high
>importance, in my opinion. That use case, as I understand it, is about
>documents authored by humans for communicating information to other
>humans. People tend to care about stuff for a long time. I have some
>10 year old XML (uh, SGML) documents that I can read just fine and
>some 20 year old word processor documents that I fear are gone
>forever.
>  
>


-- 
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

Received on Tuesday, 12 April 2005 22:01:23 UTC