On Sep 9, 2010, at 11:38 PM, Ned Freed wrote:
This was a bad idea when it was first proposed (if I recall correctly)
around
ten years ago, and it's still a bad idea.
I strongly disagree.
Whenever you define an alternate representation of something, there will
inevitably be skew between the original representation and the alternate
representation.
This is demonstrably false. The Sieve in XML representation specified in RFC
5784 provides a counterexample - the way the format and mapping is defined,
there's no way to represent anything in the XML variant that cannot be
represent in the regular variant, and vice versa.
RFC 5784 might well be a valiant effort toward that. But it has only been
out a few months, so I think the jury is still out as to how well it works in
practice.
I'm still not hearing specifics as to how such a failure can occur, either
in the Sieve XML mapping or the iCal one.
Like most engineering problems, the devil is in the details, which aren't
addressed in any useful fashion by sweeping pronouncements about what
should or should not be attempted.
A mapping to and from XML can be done well or done badly. A good mapping
doesn't require schema and mapping tool changes to accomodate extensions, a bad
mapping does.
Let's look at a specific example. An 'fileinto "foo"' action in Sieve is mapped
by RFC 5784 to XML of the form:
<action name="fileinto"><str>foo</str></action>
Suppose we had chosen;
<fileinto>foo</fileinto>
instead. Or maybe:
<action name="fileinto" arg="foo"/>
Both of these mappings are much simpler and easier to read, but they have a
major failing: The former requires a schema change in order to add new actions,
and the latter requires a schema change to accomodate any sort of extension to
fileinto. By using XML elements to represent the syntactic structure of Sieve
only, we create a situation where only a change to the fundamental syntax of
Sieve - something the base specification specifically prohibits extensions from
doing - is capable of forcing a change to the schema.
iCal has a similar core syntax to Sieve that extensions have to fit into and
cannot change. It follows that as long as that's all you try and represent
using XML elements, extensions will not necessitate a schema change and it
should be possible to write tools to perform the mapping that don't need to be
updated when extensions are defined.
Unfortunately, now that I've had a chance to look at
draft-daboo-et-al-icalendar-in-xml-06.txt a little more, I find that it doesn't
do this well. For example, instead of mapping a property like dtstamp to
something like:
<property name="dtstart">
<date-time>20080205T191224Z</date-time>
</property>
it maps it to:
<dtstamp><date-time>20080205T191224Z</date-time></dtstamp>
This means that additional properties will necessitate a schema update. Not
good, and I believe this needs to be fixed.
I also think it helps that RFC 5784 specifically says it's not intended as an
alternate storage format for Sieve. I can certainly see some utility in being
able to use XML tools to manipulate things not originally written in XML.
It helps in the sense that it makes it clear who needs to support the alternate
format and who doesn't. But it has no effect at all on the issue of how the
mapping accomodates extensions.
But here's the acid test. If you can define a mapping from iCalendar to XML
that doesn't require any string constants to describe it (other than for
iCalendar keywords that imply nesting, and separators that are used in a
regular fashion in iCalendar), and if you can define the inverse mapping from
XML to iCalendar without naming more than a couple of specific element or
parameter names - then I'll concede that the mapping will probably continue to
work in the face of extensions to the iCalendar data model. Otherwise, I'm
highly dubious.
I agree that this is what's needed. I don't think it's that difficult to do
though. And I don't think it is difficult to evaluate whether or not that goal
has been reached: All you have to do is look at the extensibility model, and
make sure that anything that conforms to the extensibility model isn't going to
require a schema change.
Even then, this would not address the degraded interoperability resulting
from the need to have multiple formats.
It's just not this simple. The loss in interoperability may be made up for by
the increase in accessibility by a different and very powerful set of tools.
I have only done a cursory review of iCalendar in XML specification, but I
believe it covers this issue adequately, and according to the document, it
clearly intends to define a format that fully support round trips between
the
representations. If you believe it does not, it is up to you to provide
specifics of how it does not, rather than asserting there's a problem
without
any actual evidence.
I disagree, because there are interoperability problems resulting from the
introduction of an alternate format even if the mappings remain invertable in
the presence of extensions.
I'm sorry, but proof by assertion still isn't working for me here.
This remains true even if you define mapping rules between the two (as you
do
in this document). The problem with mapping rules, which I believe I
pointed
out around ten years ago, is that the rules are specific to a particular
version of iCalendar. If either iCalendar is extended, or the XML
representation is extended, there's no guidance as to how to map the
extended
format into the other representation.
Also demonstrably false, and once again RFC 5784 provides a counterexample.
When Sieve extensions are defined the only thing that ever needs to be
updated
in the mapping to accomodate them is the list of controls, which is needed
to
map to the XML format.
I think you've just illustrated my point.
Tsk tsk. You're quoting me out of context, having removed the part where I said
that this update could have been eliminated had we chosen to do so. In XML,
there's a tradeoff between what I'll call readability (it's actually quite a
bit more than that) and easy extensibility.
Though really I'm not as worried about Sieve as I doubt that there's nearly
as much deployment of Sieve as there is of iCalendar.
There are demonstrably many millions of users using Sieve. The number of iCal
users is probably several orders of magnitude larger, but regardless, these
are both widely deployed formats.
(Of course most of the people using either Sieve or iCal are unaware that's
what they are using. Which is as it should be.)
I think it's far more likely that all Sieve implementations can be upgraded to
support XML, if there's a desire to do that, than that all iCalendar
implementations can be upgraded to support XML.
I doubt very much that all Sieve implementations will be upgraded to support
both formats, nor was that ever the intent when the XML variant was defined.
I also think that Sieve<>XML is inherently saner than iCalendar<>XML because
Sieve (being essentially a programming language) is already structured
similarly to the way XML is structured.
Sorry, I'm not seeing the major distinction here. It's just neesting of
structures in either case.
Again, if you believe that introduction of new iCalendar properties will
require updating the mapping to an unaceptable degree, it is up to you to
cite
specific exmaples instead of just asserting there's a problem.
I think that the burden is on the proposers to justify producing an
incompatible alternative to a existing standard, which will definitely harm
interoperability.
And now you're asking the authors to prove a negative.
In addition, defining a new calendar format harms interoperability even if
you can keep the two representations in sync. The reason is that it's no
longer sufficient for a calendar application to support just one
representation
of calendar data. In order to reliably interoperate, it must at least
able to
read both, and it probably needs to be able to write both. That, and when
sending calendar data to other applications, either both representations
must
be sent, or some way of negotiating which format to use is needed, or the
user
must be asked to choose which format to export.
Yes, the existence of multiple formats can be an issue, but so can the
inability to easily manipulate application data in popular environments
using
readily available tools. IMO the tradeoffs in this case are
*overwhelmingly* on
the side of being able to manipulate calendar data using XML tools.
If people want to define mappings between iCalendar and XML just for the sake
of being able to manipulate the data using XML tools, that doesn't bother me
so
much. It's when people want to start exchanging calendar data using XML in
some cases and iCalendar in others that the interoperability problems start
cropping up. (Though I have to wonder how much it really helps to be able to
manipulate calendar data using XML tools, as calendar manipulations tend to be
fairly specialized to calendar applications.)
Even if XML-specific tools like stylesheets prove less than useful in
performing manipulations of calendar data, there's still significant benefit
associated with being able to use built in parsing capbilities, espcially when
those capabilites are nicely tied to automatic creation of complex data
stuctures in various languages.
Ned
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf