Re: [wemi] WEMI Questions Document

[Thomas Lund Sigdestad <tsi@enonic.com>]

Hi!

Just want to emphasize part of what I wrote below, as there seems to be a misunderstanding:
The wemi document for the site (root resource) could obviously contain a "sitemap" with additional links for the rest of the site - if desired. So this approach should cover all scenarios for retrieving wemi-data for any given site or resource.

The reason for exposing a wemi-location as header as this is more likely to speed up adoption on the serverside, as it might be simpler to implement this on other different urls. I think this might be an obstacle for many implementors, escpecially when thinking of solutions that are not content-driven, or when people want to secure wemi access etc. etc.

I struggle to see how checking a simple http header adds much complexity?

As for bindings - one is truly enough for now, just getting exited :-)

Vennlig hilsen/Best regards
Enonic AS

Thomas Sigdestad
CTO
+47 98236011

An Open Source Company

---

From: "Martijn van Berkum" <Martijn.vanBerkum@gxsoftware.com>
To: "Serge Huber" <shuber@jahia.com>
Cc: "Thomas Lund Sigdestad" <tsi@enonic.com>, "Peeter Piegaze" <ppiegaze@adobe.com>, "<wemi@lists.oasis-open.org>" <wemi@lists.oasis-open.org>
Sent: Tuesday, October 2, 2012 11:14:18 AM
Subject: Re: [wemi] WEMI Questions Document

On 2 Oct. 2012, at 09:54 Serge Huber <shuber@jahia.com> wrote:

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