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

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

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


Subject: Re: [cmis] unreadable property names and current clients?


Hi Jens,

On 4 Mar 2009, at 12:21, Jens Hübel wrote:
> I have a question how the typical clients behave in regards of  
> property names today.
>
> Properties have a name, an id and a query name. A property  
> definition also has a display name. In a getChildren() or  
> getProperties() call a property is identified by its name. Property  
> names  have certain syntax constraints. So it might happen that a  
> repository needs to map its internal property identification to  
> something that fulfills the CMIS syntax. This could be a generated,  
> meaningless string  like PROP_4711. Only the property definition  
> then contains something readable in the displayName like "Invoice  
> number". All the examples in the spec however contain readable  
> property names.
>
> So my question is: Will existing CMIS clients today display the  
> property name directly in the user interface or will they typically  
> do a look-up in the property definition for the display name before  
> presenting this in the user interface?
>
> Any feedback is welcome how you have implemented this today. Would I  
> break clients by using a generated, unreadable property name like  
> PROP_4711? Do we need to define a recommendation in the spec (in  
> this case I would create a JIRA issue).

We haven't fully implemented our client yet, but it was always our  
intention to use the Property Definition's DisplayName ("This  
attribute is used for presentation by application"). All the other  
names/ids are technical ones, and not fit for a human UI (although of  
couse making them readable helps a lot of things). For instance they  
can't have spaces in them, which makes them unsuitable for many  
property names.

Florent

-- 
Florent Guillaume, Head of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com   http://www.nuxeo.org   +33 1 40 33 79 87



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