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


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
>



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