> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf