OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wemi message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [wemi] WEMI Questions Document

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.
  • +1 on the seperate endpoint. From a WEMI consumer perspective, this again makes it quite easy to use.
  • 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?
  • 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
  • 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).
  • 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

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


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

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]