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 :-)
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/>
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 :-)
Thanks for listening.
Vennlig hilsen/Best regards
Enonic AS
Thomas Sigdestad
CTO
+47 98236011
An Open Source Company
From: "Peeter Piegaze" <ppiegaze@adobe.com>
To: wemi@lists.oasis-open.org
Sent: Tuesday, September 25, 2012 6:29:13 PM
Subject: [wemi] WEMI Questions Document
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
(Let me know if there are any problems with this link)
Cheers,
Peeter