Greg Hudson wrote:
A generic XML editor isn't going to know much about the semantics of the
document it is editing. It's not necessarily going to be a good
framework for a whiteboarding application, any more than emacs is a good
foundation for Photoshop. They both edit files, but...
Nobody is suggesting deploying a single editor for two different
applications. We are suggesting that although the two editors would be
designed for incompatible applications, they could talk the same
protocol at the lowest level, and that they could therefore share a code
library (just as many very different applications might use the same
database engine).
I would have thought that, a *very low level* synchronised XML editing
protocol suitable for SVG documents could be very similar to, for
example, one for XHTML documents.
1. What significant differences do people see between two such *lowest*
level protocols?
2. Could those differences be optional parts of a single low-level protocol?
3. What specific real-world disadvantages do people see if we use a
single low level building-block protocol?
All XML editing applications share the same major challenge, i.e. the
various issues surrounding synchronization. IMHO, the
application-specific protocol issues tend to be relatively trivial to
work out. So if we standardise on a good extensible synchronization
protocol then we will facilitate many applications and avoid protocol
designers reinventing the wheel.
- Ian
