On 10.09.2010 16:48, Ned Freed wrote:
> ...
> 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.
> ...
Not really. How is adding a new allowed value to an XML attribute any
different from adding a new element name (assuming a schema language
than can express both constraints?).
First of all, there are many situations where you don't get to pick your schema
lannguage. (In fact I'd say it's the rule rather than the exception.) So even
there are Schema languages that support "any element can appear here" - the
fact that XML Schema doesn't allow this (xs:any has far too many restrictions
placed on it to be usefullly usable) means you shouldn't be defining things
this way.
Second, it is of course possible to impose restrictions on the values that can
appear in an attribute value (or element content for that matter). But just
because you can doesn't mean you should. And these sorts of mappings are
exactly the place where you shouldn't be doing this, at all, ever, because when
you do you end up having to change the schema for each extension that adds
properties (in the case of iCal) or actions/tests/controls (in the case of
Sieve).
Furthermore, in the case of Sieve at least, there are cases where it is
entirely valid to specify tests and actions in a script that the implementation
you're currently using doesn't support. For example:
require "ihave";
if ihave "ereject" { ereject "I hate this message"; }
elsif ihave "reject" { reject "I still hate this message";}
else { discard; }
or:
require "ihave";
if ihave "x-private-extension-nobody-else-has-heard-of" {
if bletch "bar" "foo" { frob :zing "foo" 1 "bar";}
}
If I've mapped actions and tests to elements here I'm screwed - there's no way
to make this work properly in XML Schema without either adding a ton of
superfluous bracketing elements all over the place (and we already have too
many of these), or creating a false distinction between extensions and base
elements that is, if anything, even uglier.
It's also easy to show that full script validity checking here requires solving
the satisfiability problem, which means its in NP. I'm pretty sure that exceeds
the capabilities of most schema languages ;-)
I believe similar issues exist in iCal and probably vCard.
Ned
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf