[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mnot-03, Infoset & syntax in sect. 2


On Dec 27, 2003, at 3:02 PM, Bob Wyman wrote:

	What I would like to see is a world where the following
conditions hold:
	1. All publishers who provide data directly to end-users are
expected to provide that data as RSS, Atom, or whatever in XML format
-- complete with pointy brackets, etc.
	2. Publishers who want to be more "aggregator friendly" have
the *option* of providing an additional feed which is an ASN.1/PER
binary encoding of the XML Infoset. (Parses faster, is much more
compressed than XML and provides semantic equivalence with the XML
feeds. (i.e. application/atom+per == application/atom+xml))
... 
	The problem with the kind of blind opposition to the binary
feeds that Tim Bray brings to this thread is that it makes it hard to
get discussion going on a *standard* binary encoding for the Infoset.,

Actually, such discussion has been started and is well under way; the W3C held a workshop on it and is chartering a working group to explore requirements; see <http://www.w3.org/2003/08/binary-interchange-workshop/Report>.

It is not controversial that there are a number of different communities who have requirements for XML processing ranging across the space of data size and processing speed. What is still controversial is the notion that there is a *single* alternate encoding that is going to cover a broad enough spectrum of the requirements to make sense standardizing on. I genuinely have no educated opinion on this; my intuition, just based on listening to the requirements, is that they're just spread too far all over the map and there's unlikely to be a single broad-spectrum solution, but I haven't investigated this very deeply.

Mr. Wyman is an ASN.1 partisan who tends to see that as a solution for a lot of problems, including that of making XML quicker and smaller. I really don't have an opinion on whether he's right; I've never been successful working with ASN.1 because I always had trouble with tool price/quality/availability.

	As you say, we should "define the bits on the wire". Hear!
Hear!... Let's just make sure that we make it possible to define the
binary bits as well as the text bits...

We can cover that just fine with some combination of MIME, base64, whatever. You're arguing that there is a serious high-priority problem with size and parsing speed, and further that ASN.1/PER is the answer. I don't have enough evidence yet to have an opinion on either of those points. In the short term, we are in the process of defining Atom as an XML 1.0 vocabulary, and that's just fine.

Cheers, Tim Bray http://www.tbray.org/ongoing/