W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2009

Re: skipping and ignoring

From: Marcos Caceres <marcosc@opera.com>
Date: Fri, 25 Sep 2009 13:04:15 +0300
Message-ID: <b21a10670909250304y2bfc8d2dlc26af510654a2813@mail.gmail.com>
To: Robin Berjon <robin@berjon.com>
Cc: public-webapps WG <public-webapps@w3.org>
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:(

Kind regards,
Marcos

-- 
Marcos Caceres
http://datadriven.com.au
Received on Friday, 25 September 2009 10:09:31 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:33 GMT