On Fri, Sep 25, 2009 at 12:04 PM, Marcos Caceres <marc...@opera.com> wrote: > 2009/9/24 Robin Berjon <ro...@berjon.com>: >> On Sep 23, 2009, at 16:51 , Marcos Caceres wrote: >>>> >>>> But instead of ignored it says skipped — and it's not clear >>>> whether skipped has the same meaning. >>> >>> Good point. The second must not be processes because it is not the >>> first. It don't matter that is serviceable. It might just be that I >>> used ignore where skip was intended. >> >> That's not a very strong versioning approach. >> >>>> If the second element is not taken into account, then we have a potential >>>> problem with forward compatibility. Let's imagine that we have v2 out, for >>>> which the following is correct: >>>> >>>> <content uri='http://berjon.com/cool-widgets/dahut'/> >>>> <content src="perfectly-good-start-file.html"/> >>>> >>>> Clearly the desired behaviour is for v2 runtimes to process the first, and >>>> v1 runtimes to fallback to the second. >>> >>> IMO the correct behavior would be for src attributes to take URIs and >>> for the second to be skipped. However, I'm sure you can dream up other >>> examples. >> >> Yes, I can. >> >>> The "only ever use the first, even if b0rked" behavior is based on >>> HTML's behavior (particularly the <title> element). I'm happy to break >>> ranks with HTML parsing if that is what the WG thinks would be best. >>> However, it's a pretty big change to the parsing model, but if it >>> future proofs us, then it might be worth it. >> >> HTML has that behaviour to unify the mess that browsers are — there's a >> rationale there. We don't have to stick to the same thing because we really >> don't have that baggage. And thankfully this affects not at all the parsing >> model, but only processing — which is a lot easier. >> >> Furthermore I'm not convinced it's a change — we'd have to ask implementers >> which one they picked. > > It's a change. > >>>> The same issue applies to other elements that refer to the skip/ignore >>>> distinction. We believe that some editorial improvements to those >>>> definitions would be welcome. >>> >>> Agreed. I'll work on improving those but that depends on if we change >>> the parsing behavior or not to match what you suggested above. >> >> The definitions need to be improved either way. I don't have a strong >> opinion as to whether the change should go through or not so long as it's >> clarified. The modification concerns cases that aren't all that common. I >> have a preference for the more versioning-friendly approach of just skipping >> (which is also slightly simpler to implement since you don't need to >> remember anything). But if it risks being considered substantial I don't >> want it. >> > > Well, you can easily see how substantial it is given the number of > tests that have been written into the test suite to specifically test > this behavior (use the first, skip the rest). > > Now I am concerned about screwing forward comparability. Personally, I > want the format to be as forward compatible as possible. > > I'll see if I can check what Windows Mobile 6.5 does (I think PPK has > a Windows Mobile phone) and also check what Opera's internal > implementation does. > > Until then, unsure how to proceed:(
Consider the following condition, where we are trying to derive "widget.name" and "widget.shortname". What happens in the following situation: <widget ...> <name short="www"/> <name>xxx</name> <name short="yyy">zzz</foo> <name>aaa</name> </widget> Parsing Options: Option 1. "Take the first, forget the rest": Only takes the first element into consideration (current model). Option 2. "Property seeker": actively searches the elements in order for the value sought; uses the first one it finds. Option 3. "You declare it, you get it": the parser uses the last declared, overriding already declared values. Now, if we apply each: Option 1 widget.name = null widget.shortname = "www" Option 2 widget.name = "xxx" widget.shortname = "www" Option 3 widget.name = "aaa" widget.shortname = "yyy" All of them yield different result sets. I'm thinking that we are sticking with Option 1. -- Marcos Caceres http://datadriven.com.au
