W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2009

Re: [Widgets] Widget Gallery RSS like sharing format

From: Robin Berjon <robin@berjon.com>
Date: Wed, 18 Mar 2009 16:18:38 +0100
Cc: public-webapps WG <public-webapps@w3.org>
Message-Id: <57AC3613-6796-4D8F-AD13-EF9CF89EDE93@berjon.com>
To: Andrew Welch <andrew.j.welch@gmail.com>
Hi Andrew,

On Mar 18, 2009, at 13:34 , Andrew Welch wrote:
>> The idea is that in version 1.1, 1.2, perhaps even 2.0, 3.0 we just  
>> add
>> elements and attributes, and when they are not understood they are  
>> simply
>> skipped.
>
> Ok, but you do of course open yourself up to typos not revealing
> themselves until quite far down the line (after parsing anyway)

Which is just a fact of life in HTML, SVG, etc. If you want to check  
your code, use a validator. It's not the UA's job to validate, the  
UA's job is for end-users, it's not a development tool (especially not  
a mobile UA).

>> For one, errors that the end-user can't do much about should be  
>> proscribed
>> as much as possible. If your phone tells you you need a v2 user  
>> agent,
>> there's not much that the average user can do.
>
> ...but at least you'll know why it's not working, as opposed to it
> just not working.  With explicit versioning, there's potential for the
> client to update itself.

You're thinking about the developer here. The developer has oodles of  
tools available to figure out why something is not working. For the  
end-user, with must-ignore rules the widget will work (or at least its  
configuration will), there just might not be all the advertised bells- 
and-whistles.

Where is comes to the client updating itself, it certainly won't be  
because it sees a widget configuration file with a new version number.  
That just doesn't happen (and is potentially covered by an Apple  
patent).

>> You also don't address the case of a user stating that a document  
>> is v1 but
>> using v2 features. That's going to happen a lot, not just because of
>> copy-pasting but simply because people don't know which version  
>> added what
>> feature. Do you know which version of HTML added sup, blockquote,  
>> listing,
>> tab, font, math, em, or the script attribute on form?
>
> I think of it in reverse - if you want to use feature x, you know need
> at least version x.

But how do you know that? Are you supposed to keep it all in your  
head? Without looking it up, can you tell me which minimal HTML  
version needs to be supported by a browser for each of the HTML  
elements I list above? I know I can't, and frankly I think I'd be hard- 
pressed to find a list of five people who can.

> Equally, decent editors will tell you when there's a problem.

I have a decent editor and it's not telling me anything. Seriously  
though, the sort of editor you're thinking of is an IDE, and a large  
proportion of web developers hate those with rare intensity  it's not  
a solution except for Java programmers, who are hardly the core  
constituency we're addressing here.

> At least with explcit versioning, you know you want feature x from
> version 2.0, but your device currently only supports 1.0 - you don't
> have to try it and see....

That's an unrealistic situation. Implementations don't ship at version  
boundaries. There will always be implementations that support part of  
2.0, and maybe all of them will support just some useful bits of 2.0  
that you then know you can use. You've just reminded me of another  
downside of version-flagging: implementers lie. They might not do it  
on purpose, but they do do it. And frankly they have a point: if an  
implementer supports a useful subset of v2, is he supposed to just  
report supporting v1 until he's finished? What if he supports  
everything in v2 except one feature? Do you think that a specification  
will be enough to scare them into not declaring support for v2? Do you  
have the money to hire Causa Nostra dispatchers to scare them into  
submission?

The fact of the matter is that you *always* have to try and see (or  
reuse the analysis of someone who has tried and seen for you).

This is one of the primary issues with creating XML vocabularies: it  
gives one the impression that just by adding an element or attribute  
some functionality will magically appear. That's not unlike thinking  
that increasing the speedometer's range on a car will make it faster.  
Adding a version attribute will not make compatibility issues  
disappear, will not help developers deploy interoperable content, will  
not help end users figure out what's going on.

> The two issues I see are:
>
> - ignoring things you don't know means you discover problems like
> simple typos late in the day, I thought the web was moving towards
> stricter processes?  :)

We tried moving to stricter processes, it didn't work. The current  
move is in defining fallback and error behaviour (or which versioning  
is one aspect) so that interoperable content is easier to produce.

> - how do you know which schema to validate the xml with?  Given a lump
> of xml that looks like a widget config, how would you decide which
> version of the schema to use to validate it with?  Or would you not
> validate it, and just let it fail during processing?

Schema? What schema? We don't need no schemata. If you want to  
validate, then you use a validator since it's likely a schema won't be  
able to validate every constraint. A validator may allow you to  
specify which version you want to validate against, or perhaps which  
set of features. But that's a tooling issue, not something that needs  
to go in the specification because it doesn't change one's ability to  
be able to produce interoperable content.

And it won't "fail" in processing, it'll just ignore what it doesn't  
understand.

> I'm still not totally convinced either way, but I do see the benefits
> of explicit versioning, and not really any drawbacks...

Explicit versioning without attached processing rules (i.e. just  
having a version attribute) is just adding a useless attribute. It  
doesn't do anything. The problem is in specifying processing rules  
that match usage, that lead to better interoperability, and that lead  
to a workable upgrade path in a massively heterogeneous environment.  
Processing rules that do anything with explicit versioning help with  
none of the above.

-- 
Robin Berjon - http://berjon.com/
     Feel like hiring me? Go to http://robineko.com/
Received on Wednesday, 18 March 2009 15:19:15 GMT

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