Re: [wemi] WEMI Questions Document

On Mon, Oct 1, 2012 at 3:55 PM, Martijn van Berkum <Martijn.vanBerkum@gxsoftware.com> wrote:

Hi Peeter,

Great document! Explains where we stand right now very clearly. Some remarks and questions I had while reading it:

4.1: +1 on having JSON only wemi sitemap, no XML, mainly from an ease of development perspective (for a WEMI consumer). It's tricky to create our own sitemap definition, diverging from the sitemap standard, but JSON-only makes it much more approachable. Google (or other searchengines) indexing would be harder though, Google doesn't index JSON files.

There would be no disadvantage with respect to search engine indexing, since the WEMI sitemap would be used only by WEMI aware clients. Existing search engine sitemaps would presumably still be present and function as usual. The point is to separate the two things. The only thing they really have in common is that they are both "site maps" in some generic sense. We should probably call ours something different, like "wemi-sitemap.json" or "wemimap.json".

7.2.1.2: +1 on the seperate endpoint. From a WEMI consumer perspective, this again makes it quite easy to use.

Yes, I tend to agree. I just wanted to make clear what the options were so no one can come back later and say "hey, why didn't we do it that way?"

8: I tried to understand exactly what you mean in chapter 8 about the resource types, especially the word section, can you explain it a bit more wednesday? I think you want to change the name of the resource type from section to object and reintroduce section in a lower level?

Yes, I was just musing about different ways to categorize the parts of a wemi page. I think people found it a bit confusing in earlier conversations when we mentioned sections, since some people meant actual sub parts of a page, while others meant it in a more general sense, as any addressable piece of content. The clearer we make our terminology the fewer problems we will have in explaining the design.

8: Extensibility for basic types sounds great but it could lead to fragmentation because every CMS will introduce their own extensions for their proprietary (parts of) contenttypes. Would be great to cover most usecases without extensibility imho

Again, I agree with you here. The idea of "extensibility" is often talked about in standards efforts because it sounds nice and inclusive but the reality is that the simpler and more precise you make a standard (assuming it actually covers what its supposed to cover) the more likely it is to succeed.

9.2 I think using a dot syntax would be the most readable and elegant option. Using the ! looks weird, and could lead to problems with some http gateways choking on it (because they don't follow the encoding rules strictly enough).

I like the dot syntax too.

10 I could imagine usecase for (optional) metadata like: name, version, author, description, keywords, charsets and language (bases on HTML5 meta data spec, for example here: http://www.w3schools.com/tags/tag_meta.asp). Especially use cases where someone has to choose some kind of contentobject from a list and wants an idea of whats in it.

Maybe it's a good thing to also write down a bit of the design philosophy/principles for version 1.0 of the WEMI spec, or i? I can imagine something like this (I think most of them from consenus in the group?:

We strive for the KISS principle
We try to design as simple as possible, but not simpler than that
Implementation of a WEMI consumer should be not too hard
Implementation of a simple WEMI consumer should be really easy and straightforward for a relatively inexperienced developer

We try to build an simple 1.0 version of the standard instead of trying to cram every usecase on earth in it
We try to provide use cases for most of the spec features
We introduce extensibility only when we decide that there are too many strong use cases that are too complex to have in a 1.0 version of the standard, but we want to support them anyway.

We try to create examples, proof of concepts and implementations as soon as possible to progress our understandig

Martijn

Op 25 sep. 2012, om 18:29 heeft Peeter Piegaze <ppiegaze@adobe.com> het volgende geschreven:

Hi,

Thinking about the proto-spec that we have been looking and commenting on I realized that it may have been somewhat premature to get to that level detail before we answer some fundamental questions about the design of WEMI. So, I have put together a document that walks through a number of questions that need to be answered before we move on.

Please read through it and feel free to comment.

We will use this document and any feedback we get as the basis for our October 3rd meeting

https://docs.google.com/document/d/1XcPIZX15uitO_CDuELkHy_QzTAEuPSb7-u9uBoJ1UdM/edit

(Let me know if there are any problems with this link)

Cheers,

Peeter

wemi message