Re: skipping and ignoring

On Fri, Sep 25, 2009 at 12:04 PM, Marcos Caceres <marcosc@opera.com> wrote:
> 2009/9/24 Robin Berjon <robin@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

Received on Wednesday, 30 September 2009 12:59:34 UTC