Fw: [cmis-browser] Initial Comments

[Gregory Melahn <melahn@us.ibm.com>]

David,

I got back a mail server error, so I am resending.

Some may see duplicate messages.

Gregory Melahn
STSM
IBM Lotus Quickr - http://www.ibm.com/lotus/quickr
melahn@us.ibm.com
919 254 0295

----- Forwarded by Gregory Melahn/Raleigh/IBM on 08/09/2010 10:42 AM -----

From:	Gregory Melahn/Raleigh/IBM
To:	David Nuescheler <david@day.com>
Cc:	cmis-browser@lists.oasis-open.org
Date:	08/09/2010 09:32 AM
Subject:	Re: [cmis-browser] Initial Comments

---

Hello David,

Thank you for reviewing the document.

#1 It makes sense to add use cases.  I am not sure why  the batch use case is a browser binding one, in particular   It would seem like a use case that would apply to the CMIS domain model, and maybe a  v2 candidate.   

#2 ok

#3  There were conflicting opinions on the datetime format, and the latest is to use the # ms since 1970/1/1.     

#4 I am not sure what to do about that

#5 I think the autoformatting issues were resolved in the latest version (per Ryan's earlier comments).

As far as process, I am open to other approaches to move the document along   Following your idea about Google Docs, I uploaded the latest document to Google Docs and shared it with the SC roster.    I am not sure yet of this is the way to go since it makes formatting harder and tracking changes harder, but we can discuss it.

I would like to use Jira for specific issues instead of email, and then we can use part of the regular TC meeting to review them.  There is not a new component yet but I will bring it up at the TC meeting later today.

Gregory Melahn
STSM
IBM Lotus Quickr - http://www.ibm.com/lotus/quickr
melahn@us.ibm.com
919 254 0295

David Nuescheler ---08/09/2010 05:21:08 AM---Hi All,

From:	David Nuescheler <david@day.com>
To:	cmis-browser@lists.oasis-open.org
Date:	08/09/2010 05:21 AM
Subject:	[cmis-browser] Initial Comments

---

Hi All,

I finally had a chance to quickly go through the document.

I am happy actually make some of the edits later directly in the
document, but I thought I'd ask for comments on a couple of things
here first:

---------------------
(1) I think we should cover the usecases (sort of: "what are we trying
to achieve with this binding") in the document.
and of course I agree that it includes the simple consumption by a
browser for reading (via js and display in a browser), simple write
(via js and form post file upload).

I took the following from:
http://xml.coverpages.org/Nuescheler-CMIS-BrowserBindings.pdf

---
3.1 Simple Reading
A simple browser based application should be able to retrieve content
from the repository and make  sense of the properties and display
documents (content stream).
The specification should allow the simple build of a “CMIS browser
application” with just a few lines of javascript to satisfy the
mash-up use case.
After browsing for a “document”, the “document” should be displayed
with a proper resolution of all the relative references pointing to
other documents in the CMIS repository.
When displaying a document in a browser (such as an HTML file) the
relative URL references need to be kept intact, this includes for
example typical HTML elements like
<a href="”other.html”> or
<img src="”images/my.png”>.
3.2 Simple Writing
Creating a simple HTML form in a browser should be enough to update
properties and the content stream. The names of properties
(potentially the relative paths) are addressed using form field names
in the browsers.
Just uploading a file is as simple as having one
<input type=”file”>
posting the form to the parent folders child list.
To create a custom way to update or create content in CMIS is as
simple as setting up a simple web form and POSTing it to the
respective URL identifying the document or folder.

3.3 Batch Writing
Posting a number of documents to the repository or modifying a larger
number of properties in the repository is as simple as creating a more
complex form.
Given the fact that some operations are not expressed in a simple and
efficient manner by the form
fields name value pairs,  a “patch” mechanism can be used that is
applied against the repository.
This provides a more efficient way from a network perspective but also
allows javascript applications to interact with the repository from
the browser client without having to simulate full form submissions.

---

---------------------
(2) I think it would be great if the examples also had the full
response, currently they only have headers for the request.
---------------------
(3) The date format specified seems to be a timestamp and the date
format used seems to be be the iso-8601. Since the goal is probably to
keep things as simple as possible i would like to propose to use the
format as loosely proposed by Date.toString() (eg. Mon Aug 09 2010
10:57:07 GMT+0200 (CET)) since the iso-8601 is a nightmare to parse on
the client-side and the timestamp is meaningless to humans.
---------------------
(4) While JSON responses and proper HTTP response codes seem
reasonable to go with it is hard to impossible to get to the
information depending on the browser and the operation. Assuming that
someone would do a file upload with a multipart post there is no way
for a js operation to get to the response. It seems like the only way
to respond to that so it can be processed by a javascript application
is to respond with a 200 and an HTML response, which of course is very
undesirable.
---------------------
(5) The spellchecker and auto-correct functions seem to have created a
bit of a mess ;) There are a number of things like "cmis:objected" and
interesting quotation marks, but i think it makes sense to go through
that a later stage.
---------------------

I am happy to log all of the above as JIRA issues but I think we don't
have a component yet. Are there any ideas/guidelines on how we want to
log these issues?

What do you guys think of doing the authoring process in a google docs
document that would give all the editors access?

regards,
david
--
David Nuescheler
Chief Technology Officer
mailto: david.nuescheler@day.com

web: 

http://www.day.com/ http://dev.day.com
twitter: @davidnuescheler

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php