Re: [wemi] WEMI Questions Document

On Mon, Oct 1, 2012 at 6:06 PM, Thomas Lund Sigdestad <tsi@enonic.com> wrote:

Hi Peeter!

Thanks for clearing things up :-)

I have been thinking a lot about the concepts and approace to WEMI and have a few suggestions:

1. I am not sure we really need a "sitemap" for WEMI. I believe it is really the resources/urls of a site (or any other given webapplication for that matter) that should provide WEMI support. A client might start anywhere in any site/structure - and it will likely be highly interested in this resource. Thus I propose that _any_ resource might serve WEMI info about itself - not only html pages.

Example: It should be possible to get wemi-data for an image. I.e. metadata urls to other sizes ready for use etc. Same goes for any other type of resource as well. Given this approach we could in time provide standard json formats for a lot of different assets out there :-)

I wonder if that's not where the "sitemap" or "resource map" if you prefer, comes in. Or at least for a binary data resource we need to have some parent object that contains metadata about it (unless we want to expose this through custom http-headers but those are harder to retrieve with some _javascript_ libraries).

2. To obtain the WEMI version of a resource, the server could easily provide this information as part of the http header (which will work for any given type of http resource). Optionally it should be available through a specific url-format as discussed - By adding .json to the url as you suggest, clients will easily be able to determine if this is really a WEMI document -based on the core formatting of the json returned. Most likely this will serve 404 anyways..

The only "objection" would be that for json resources you would have json.json - which to me is an unlikely usecase - and not wemi-compliant? :-). However, getting the json/wemi version of an xml resource might be an ok use case to simplify access to data without processing xml first!

To conclude: Find wemi url by inspecting header (url can then be any format), if no header is there - try adding .json to current url

3. A html-document (a page) is possible more complex than other resources, and might contain multiple "sections". As suggested earlier the idea of including sections in the wemi-format seems good. In many cases these sections might actually be the initial view of a whole application. In this case we should maybe provide a standard format for serving drilldown wemi-links specific to getting more data from this section... This will effectively serve the purpose of a "multi-level-sitemap" as described in your document. I.e. the menu-part of a page might be served this way leading clients to more WEMI resources. Maybe we should seek to use html5 semantics for this as well? <nav/>

Although I see where you are going with this, I wonder if there are a lot of cases where we want to expose HTML directly to a WEMI client ?

4. In a future version? In order to let people ship structured content (and semantics) as part of a WEMI document, we could do this by letting them serve the schema together with the data! The schema could be highly simplified describing available properties, type-info, mandatory etc. in the json data just besides it.

Finally, we need to make sure that our efforts here add additional value (and most importantly - simplicity) beyond HTML5 microdata and the OData standards. I believe we are on the way :-)

I must say on my side I'm weary about all these different formats in these discussions. CMIS 1.1 has just added another binding (REST/JSON) bring the number of bindings to three, and I think we need to go the opposite route, try to make do with less. So I wonder if we even need HTML representation at this point. Although I do see value in it and definitely in some use cases, I worry that it might make things too complex on an implementation point of view. What do you guys think ?

cheers,

Serge...

wemi message