OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis-browser message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [cmis-browser] POST form data, again


Given the fact that we face more restrictions than case sensitivity on form field names, I agree that i sounds we are back to the original idea of using the form field values to hold both the cmis property id's and cmis property values, and also use the same idea for setting ace's, policies, checkin comments, etc, and then define a convention to naming the form field names so the server knows what to do with them,

I created Jira issue702, http://tools.oasis-open.org/issues/browse/CMIS-702, for documenting the details of this proposal (and assigned it to Florian per our discussion on Monday).

Even though there was some sympathy for the idea of making property id's case insensitive, I no longer see a need to propose Jira issue 694. http://tools.oasis-open.org/issues/browse/CMIS-694 and we can discuss that in the TC call tomorrow. I still think case sensitive property id's is not a good idea but I don't see a need to change the spec at this point.

Gregory Melahn
STSM
IBM Collaboration Solutions
melahn@us.ibm.com
919 254 0295


Inactive hide details for Florian Müller ---01/19/2011 12:21:11 PM---You are right, there are even more restrictions on form fiFlorian Müller ---01/19/2011 12:21:11 PM---You are right, there are even more restrictions on form field names.


From:

Florian Müller <florian.mueller@alfresco.com>

To:

Jens Hübel <jhuebel@opentext.com>

Cc:

cmis-browser@lists.oasis-open.org

Date:

01/19/2011 12:21 PM

Subject:

Re: [cmis-browser] POST form data, again





You are right, there are even more restrictions on form field names.
Another reason not to force property ids into form field names but use
the values instead.

And, yes, we only need to look at form fields here. Forms are the only
way to get access to documents on the end-users desktop. Everything else
can be handled by JavaScript (I hope).


Florian


On 19/01/2011 15:02, Jens Hübel wrote:
> If I read the HTML spec correctly than there are more restrictions:
>
> ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").
>
>  From
http://www.w3.org/TR/html401/types.html#type-cdata
>
> So if we do not have any restriction on cmis ids (and want to enforce a 1:1 mapping to HTML form elements) don't we need even more escaping then?
>
> Is mapping to html syntax something that we really want to be part of the spec? I am not sure that I have the full picture where your convention would be applied. Is this just for post of an html form?
>
> Jens
>
>
>
>
> If we cannot make any assumptions about the character set
>
> -----Original Message-----
> From: Florian Müller [
mailto:florian.mueller@alfresco.com]
> Sent: Dienstag, 18. Januar 2011 17:58
> To: cmis-browser@lists.oasis-open.org
> Subject: [cmis-browser] POST form data, again
>
> Hi all,
>
> About six weeks ago I sent out the email below. It triggered the discussion about case-sensitive and case-insensitive property names.
>
> Assuming that we now treat property names case-insensitively and based on our last call, property form fields would be named something like this:
>
> cmisProperty:<propertyId>
>
> A few examples:
>
> cmisProperty:cmis:name = my%20document
> cmisProperty:my:singleInteger = 42
>
>
> That doesn't take multi-value properties into account. So, it actually has to be something like this (even for single value properties):
>
> cmisProperty:<index>:<propertyId>
>
> A few more examples:
>
> cmisProperty:0:my:mvProperty = first
> cmisProperty:1:my:mvProperty = second
>
>
> Now let's have a look at the ACEs. We cannot make any assumptions about principal ids and permission names. So, no changes of the proposal below.
> That is also true for policy ids since object ids are still case-sensitive. So, no change here either.
>
>
> Looking at all of this, I actually prefer my previous proposal.
> We wouldn't have to make property ids case-insensitive which would give us backwards compatibility to CMIS 1.0. I think that's important.
> It also feels more consistent and is easier to process on the server side.
>
> If we would change "property_name_0" and "property_value_0" to something like "propertyName[0]" and "propertyValue[0]" PHP developers would get of the field processing almost for free.
>
>
> Who can convince me otherwise?
>
>
> - Florian
>
>
> On 07/12/2010 11:43, Florian Müller wrote:
>> Hi all,
>>
>> Here are some initial thoughts on HTTP POST and how the form data could look like.
>>
>> Form fields:
>>
>> - action
>>     Action indicator. See URL patterns.
>>
>> - objectId
>>     Object id. See URL patterns.
>>
>> - property_name_<index>   and property_value_<index>
>>     Single value property value.
>>     Example:
>>       property_name_0  = cmis:name
>>       property_value_0 = my%20document
>>       property_name_1  = my:singleInteger
>>       property_value_1 = 42
>>
>> - property_name_<index>   and property_value_<index>_<listIndex>
>>     Multi value property value
>>     Example:
>>       property_name_0    = my:mvProperty
>>       property_value_0_0 = first
>>       property_value_0_1 = second
>>
>> - addACE_principal_<index>   and addACE_permission_<index>_<permIndex>
>>     ACE to add.
>>     Example:
>>       addACE_principal_0    = bob
>>       addACE_permission_0_0 = cmis:read
>>       addACE_permission_0_1 = cmis:write
>>
>> - removeACE_principal_<index>   and removeACE_permission_<index>_<permIndex>
>>     ACE to remove.
>>     Example:
>>       removeACE_principal_0    = tom
>>       removeACE_permission_0_0 = cmis:write
>>
>> - policy_<index>
>>     Policy to set.
>>     Example:
>>       policy_0 = policy-id-001
>>       policy_1 = policy-id-002
>>
>> - changeToken
>>     The change token. If unknown, it should not be set.
>>
>> - versioningState
>>     Versioning state
>>
>> - checkinComment
>>     Checkin commment.
>>
>> - filename
>>     Filename.
>>
>> - query
>>     CMIS QL.
>>
>> ...to be continued...
>>
>>
>> You might wonder why the property ids and principal names are not part of the field names. The reason is that form input names are case-insensitive.
>> A CMIS repository could expose a type with a property "my:property" and a property "my:PROPERTY" and those would be two different properties.
>>
>>
>> Any comments?
>>
>> Florian
>>
>> ---------------------------------------------------------------------
>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
>


---------------------------------------------------------------------
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 




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]