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] Scope of Hierarchical Properties


I agree with Julian's statements.

Since David C. expressed an interest in use cases I could volunteer two
very common use cases to the discussion that I happen to come across

(1) Thumbnails
After loading a document into a CMIS enabled repository it would be great
to have an CMIS application add a number of thumbnails in various sizes
into a "thumbnail" structure. Since the thumbnails themselves semanticly
should not be treated as an individual document, since this would clutter the
namespace the thumbnails should be treated as structured meta-data.

(2) Persisting and Querying XMP [1]
Since many modern file formats (PDF, JPEG, ...) support XMP data
upon ingestion the XMP information could (probably should)
be extracted by a repository (or any thirdparty CMIS app).
This should be done in a fashion that allows for query of the respective
information, since of course XMP holds a wide variety of potentially
very useful information.

While I do not necessarily advocate the inclusion of hierarchical properties
in v1.0 of the specification I think the above are fairly straight
forward common
use cases that could be considered.


[1] http://en.wikipedia.org/wiki/Extensible_Metadata_Platform

On Tue, Dec 16, 2008 at 6:09 PM, Julian Reschke
<julian.reschke@greenbytes.de> wrote:
> Hi,
> this certainly looks like a feature set that will be hard to standardize.
> Maybe it makes sense to look at how others have dealt with it?
> 1) JCR doesn't have structured properties per se, but can support complex
> hierarchies of content nodes. So the structure is not *in* the properties,
> but in the tree of nodes they are contained in.
> This approach is very flexible, and also solves the issue of queryability.
> On the other hand, it's also hard to implement on top of systems that do not
> happen to support this in the first place.
> 2) WebDAV properties can complain arbitrary XML, thus any kind of hierarchy
> *can* be represented inside a WebDAV property (*). This is extremely simple
> to implement in a repository (essentially it can treat those properties as
> strings, with only one additional flag stating it's XML).
> The drawbacks here are that the property can only be manipulated and
> access-controlled in total, and that there's no solution for query (yet).
> ...both approaches are flexible and can represent just anything; but because
> of their flexibility clients and servers are more tightly coupled (because
> they need to understand the specific format/structure).
> BR, Julian
> (*) Of course binary values would be problematic...
> --
> <green/>bytes GmbH, Hafenweg 16, D-48155 Münster, Germany
> Amtsgericht Münster: HRB5782
> ---------------------------------------------------------------------
> 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

Visit: http://dev.day.com/

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