On Wed, Mar 18, 2009 at 2:14 PM, Robin Berjon ro...@berjon.com wrote:
On Mar 18, 2009, at 11:33 , Andrew Welch wrote:
- when multiple versions of the xml exist, you need some way to
differentiate them other than checking for the existence of certain
elements/attribute
You state that as a
FWIW, as the editor, I agree with Robin. Nothing is gained by adding
explicit versioning to the spec.
ok, but I don't think you can say nothing is gained from explicit
versioning instead of implied versioning...
--
Andrew Welch
http://andrewjwelch.com
Kernow: http://kernowforsaxon.sf.net/
On Mar 17, 2009, at 13:24 , Marcos Caceres wrote:
Agreed. Thinking forward, how do you recommend we identify version 2.0
of the widget configuration file format (or should we just cross that
bridge when we get to it?) ?
Personally, I would recommend that we don't :) Version identifiers are
2009/3/17 Robin Berjon ro...@berjon.com:
On Mar 17, 2009, at 13:24 , Marcos Caceres wrote:
Agreed. Thinking forward, how do you recommend we identify version 2.0
of the widget configuration file format (or should we just cross that
bridge when we get to it?) ?
Personally, I would recommend
On Tue, Mar 17, 2009 at 1:57 PM, Robin Berjon ro...@berjon.com wrote:
On Mar 17, 2009, at 13:24 , Marcos Caceres wrote:
Agreed. Thinking forward, how do you recommend we identify version 2.0
of the widget configuration file format (or should we just cross that
bridge when we get to it?) ?
On Wed, Mar 18, 2009 at 9:35 AM, Andrew Welch andrew.j.we...@gmail.com wrote:
2009/3/17 Robin Berjon ro...@berjon.com:
On Mar 17, 2009, at 13:24 , Marcos Caceres wrote:
Agreed. Thinking forward, how do you recommend we identify version 2.0
of the widget configuration file format (or should we
On Wed, Mar 18, 2009 at 9:49 AM, Andrew Welch andrew.j.we...@gmail.com wrote:
I agree. Changing the namespace is a bad idea. I didn't get the sense
that this is what Robin was suggesting, however.
I was referring to this part:
If at some point we make breaking changes, then we just change
On Wed, Mar 18, 2009 at 1:47 AM, Andrew Welch andrew.j.we...@gmail.com wrote:
Personally, I would recommend that we don't :) Version identifiers are
largely useless and experience shows that users use them wrong (e.g. a bunch
of SVG out there that's labelled as 1.1 is really 1.2, but people
I agree. Changing the namespace is a bad idea. I didn't get the sense
that this is what Robin was suggesting, however.
I was referring to this part:
If at some point we make breaking changes, then we just change the namespace.
--
Andrew Welch
http://andrewjwelch.com
Kernow:
Personally, I would recommend that we don't :) Version identifiers are
largely useless and experience shows that users use them wrong (e.g. a bunch
of SVG out there that's labelled as 1.1 is really 1.2, but people just
copy-paste the root element).
Agreed. This is the reason we did not
On 3/18/09 9:52 AM, Jonas Sicking wrote:
On Wed, Mar 18, 2009 at 1:47 AM, Andrew Welchandrew.j.we...@gmail.com wrote:
Personally, I would recommend that we don't :) Version identifiers are
largely useless and experience shows that users use them wrong (e.g. a bunch
of SVG out there that's
I think that is what we are doing. By not including a version
identifier, we remove the temptation to make backwards incompatible
changes protected by a version switch. Those are the type of changes
that are harmful since they require more complex authoring than much
of the web seems to use.
On Mar 18, 2009, at 09:35 , Andrew Welch wrote:
Are you sure changing the namespace is preferable to a version
attribute? Seems very drastic, and usually it's best to avoid doing
it as it makes all tools that process existing markup redundant.
I didn't say that changing the namespace should
Hi Robin,
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)
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
On Fri, Mar 13, 2009 at 11:58 AM, Robin Berjon ro...@berjon.com wrote:
On Mar 13, 2009, at 08:33 , Thomas Landspurg wrote:
Good suggestion. I think RSS/Atom is well adapted for new widgets
publication. I think that keeping the platform attribute is interesting,
because we - as many - we will
Good suggestion. I think RSS/Atom is well adapted for new widgets
publication. I think that keeping the platform attribute is interesting,
because we - as many - we will have to support different format for some
time.
On Wed, Mar 11, 2009 at 2:14 PM, SUZANNE Benoit RD-SIRP-ISS
On Mar 13, 2009, at 08:33 , Thomas Landspurg wrote:
Good suggestion. I think RSS/Atom is well adapted for new widgets
publication. I think that keeping the platform attribute is
interesting, because we - as many - we will have to support
different format for some time.
The issue I see
Re: [Widgets] Widget Gallery RSS
like sharing format
On Mar 13, 2009, at 16:33 , Jon Ferraiolo wrote:
Over in OpenAjax Alliance, we are working with various players in
the industry to establish widget repositories. We have been using
OpenSearch for both the search query and the response.
I didn't know that the OAA was already using this. As
All,
Based on our last F2F, we have talked about an RSS like file format that
would standardise the widget list for various needs. I do not consider the
following as a formal format proposition but as an input to open the
discussion as it should probably be written in atom instead of RSS.
So here
On Mar 11, 2009, at 16:44 , Jon Ferraiolo wrote:
How about adopting OpenSearch response?
http://www.opensearch.org/Specifications/OpenSearch/1.1#OpenSearch_response_elements
In fact, how about simply adopting OpenSearch in its entirety?
Well my understanding of the use case is that it's
Hi everyone,
Here's a sample of our widget gallery output from Wookie - again not
as a proposition but just to share an example of the sort of content
that tends to be included in these cases.
(Note in our system the client requests an instance of a widget using
the widget identifier,
23 matches
Mail list logo
