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