[Xml-bin] Some central design issues

[Stephen D. Williams]

Al Snell wrote:
> 
> On Thu, 12 Apr 2001, Stefan Zier wrote:
> 
> > > are nearly good enough, we should try to influence these, to get the
> > > remaining 5% instead of starting all over.

These designs to not get me where I need to be.  I'll certainly learn
from them though!

> > I think we all agree on that one. Has anyone gotten any URLs or papers von
> > BiM yet?
> 
> I'd be keen!
> 
> BiM may be a stream-focussed protocol with no seekability, is my main
> worry.

I require both very efficient seekability and efficient in-place
modification.  I haven't seen anyone else consider the latter
requirement.  It's difficult, but is what is really required in a number
of key situations.

> 
> The ASN.1 project seems to be based around the idea of using a schema to
> encode data with no self-description information in it, and requiring the
> same schema at the other to make sense of it. Although there are
> applications for this, I feel a representation that you could round trip
> XML through without reference to any schemas or DTDs will be more
> generally useful and will not suffer from not being self-describing.

This kind of thing doesn't make any sense as a binary equivalent to
XML.  It may be useful for a certain class of problems, but it doesn't
have the generality that a true 'binary XML' implies and needs.

> We can probably suggested an ASN.1 based representation for a
> self-describing XML representation as a logical extension to the ITU's
> work, and get them to accept it as part of the same recommendation... not
> sure about the politics, though.
> 
> > > binXML should be an alternate external representation of the (PSV) XML-
> > > Infoset, so all XML Recs are readily applicable and it is possible to
> > > roundtrip binXML -> textXML -> binXML.
> >
> > I have to agree on this one, too. Every well-formed XML doc should be
> > representable in the binary notation and vice versa.
> 
> Definitely, otherwise we raise barriers to adoption...

Yes, although I may experimentally introduce more precise pointers and a
delta/overlay method.  While still representable in standard XML, they
won't, at first, be standardized themselves.

> > There is another requirement that might need a different orders of things:
> > fast parsability through SAX or DOM (where either of those two might have
> > different orders).
> 
> Mmmm; I have a solution for those two requireements :-)

Cool.  After thinking about it long and hard, I'm more inclined to solve
the DOM optimized problem first.  SAX is secondary to me.  True
streaming needs to be supported, but I am trying structures that may not
make it efficient without some reasonable buffering.  The latter comment
alludes to the idea of having a stream of Delta DOMs.  The 'sender'
would have to choose a buffer size that the receiver would have to
support.  I'm not thinking of Delta DOMs for this purpose, they were
created to support overlays, versioning, transactions, etc.

> ABS
> 
> --
>                                Alaric B. Snell
>  http://www.alaric-snell.com/  http://RFC.net/  http://www.warhead.org.uk/
>    Any sufficiently advanced technology can be emulated in software
> 
> _______________________________________________
> xml-bin mailing list
> xml-bin@warhead.org.uk
> http://lists.warhead.org.uk/mailman/listinfo/xml-bin

-- 
sdw@lig.net  http://sdw.st
Stephen D. Williams
43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax 
Dec2000