On Mon, Oct 1, 2012 at 6:06 PM, Thomas Lund Sigdestad
<tsi@enonic.com> wrote:
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).
This method of in-page discovery of other WEMI resources would mean that it's much harder to discover a lot/list of resources, you have to travel down all resources and retrieve them all to create a list of them. I think from a WEMI consumer point of view
this makes using WEMI harder, except if you know exactly what page/resource (URL) you want to access. And indeed, binary data like images etc need some special constructs, which makes it more complex to retrieve and discover WEMI resources, as we then have
2 mechanisms to find and access them?
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
I would say lets try to have only 1 mechanism to retrieve the WEMI version of a resource? Two makes it more complex for a WEMI consumer.
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 ?
Agree, I would vote for simplicity, and have only 1 binding if we can support enough use cases that way. We can always create more features/bindings etc in version 2 for WEMI, I would say lets try to make a simple first version of the standard.
Martijn
|