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

[Dave Pawson <davep@xxxxxxxxxxxxx>]

Saturday, December 27, 2003, 11:02:25 PM, you wrote:

BW> 	What I would like to see is a world where the following
BW> conditions hold:
BW> 	1. All publishers who provide data directly to end-users are
BW> expected to provide that data as RSS, Atom, or whatever in XML format
BW> -- complete with pointy brackets, etc.
BW> 	2. Publishers who want to be more "aggregator friendly" have
BW> the *option* of providing an additional feed which is an ASN.1/PER
BW> binary encoding of the XML Infoset. (Parses faster, is much more
BW> compressed than XML and provides semantic equivalence with the XML
BW> feeds. (i.e. application/atom+per == application/atom+xml))
BW> 	3. Aggregators, or anyone else who consumes the binary feeds,
BW> are assumed to also support feeds in XML encodings.

I see that as a reasonable position.
I'm curious if its 'corner case' though, i.e. a real minority?

I'm also curious how confident you are in the semantic equivalence
Bob?




BW> 	The problem with the kind of blind opposition to the binary
BW> feeds that Tim Bray brings to this thread is that it makes it hard to
BW> get discussion going on a *standard* binary encoding for the Infoset.
BW> This means that there are wide-open opportunities for people to push
BW> proprietary encodings

Isn't that the issue being discussed on xml-dev?



BW> 	My personal, very strongly held opinion, is that the best way
BW> to ensure that interop is maintained is to address the binary issue
BW> directly and define a *standard* binary encoding of the Infoset as
BW> well as the rules for it's use, requirements for XML-text support as a
BW> fall-back, etc. Once this is done, there will be little to justify the
BW> work of those who today see an opportunity or requirement for
BW> proprietary formats.

Is that any different to the 'proprietary' view you expressed?
Surely one of the standards bodies is the right place to resolve a
binary format?  Perhaps in preference to this forum? Certainly take
the use case you quote to such a forum.


BW> 	Tim, you flame regularly against "proprietary" interfaces. I
BW> agree with every one of your posts on this subject -- except, I
BW> disagree with your approach. To me, you sound like Nancy Reagan saying
BW> "Just say No!". I believe that the more active approach of defining
BW> standard binary encodings can eliminate the risk of proprietary
BW> formats and interfaces being defined.
BW> 	As you say, we should "define the bits on the wire". Hear!
BW> Hear!... Let's just make sure that we make it possible to define the
BW> binary bits as well as the text bits...
BW> 	But, understand that I am not suggesting that Atom define a
BW> binary format or even address the issue -- just that in the definition
BW> of Atom, nothing should be done to make it difficult or "forbidden" to
BW> produce binary encodings of Atom data if a *standard* binary encoding
BW> is ever defined and accepted.

My caveat would be to ensure its a broad need that's being addressed
first.

regards DaveP