Makes sense and I'd settle for an enclosing tag.
Jeff
Jeff,
They are type specific since fields on the property definition change such as max length on a string field, max date on date, precision on float, etc. This made the property definitions type safe so they only had the fields/elements required rather than all elements and default values and choice lists could be type-specific. If the propertydefinitions were homogenous and the semantic meaning could be conveyed by an attribute or element I would agree with you.
I believe this change to be too large to be considered at this point and would propose, if the tc is interested, that this be investigated for 2.0. If the ease of access for looping through property definitions is the issue, we could introduce an enclosing tag and its subelements would be one of the type property definitions. This would also most likely be for 2.0 as that change would require another public review.
Best, -Al
Al Brown
Office 714 327 3453
Mobile 714 251 6441.
Email albertcbrown@us.ibm.com
CONFIDENTIAL NOTICE: The contents of this message, including any attachments, are confidential and are intended solely for the use of the person or entity to whom the message was addressed. If you are not the intended recipient of this message, please be advised that any dissemination, distribution, or use of the contents of this message is strictly prohibited. If you received this message in error, please notify the sender. Please also permanently delete all copies of the original message and any attached documentation.
<graycol.gif>Jeff Potts ---01/25/2010 03:01:29 PM---Right now, the element name for a property, either when describing an entry or when looking at a typ
From: Jeff Potts <jpotts@optaros.com>
To: "cmis-comment@lists.oasis-open.org" <cmis-comment@lists.oasis-open.org>
Date: 01/25/2010 03:01 PM
Subject: [cmis-comment] cmis:property*Definition element name
Right now, the element name for a property, either when describing an entry or when looking at a type definition, includes the property type. Examples:
<cmis:propertyBooleanDefinition>
<cmis:propertyIntegerDefinition>
<cmis:propertyStringDefinition>
I realize that one advantage of the current scheme is that the server can determine the property type by looking at the element name without further parsing.
Despite that advantage (maybe there are others?), this feels bad for at least a couple of reasons. It makes it painful to grab the collection of property definitions, for example, especially because they aren't enclosed by a common root element. Plus, it just seems like a bad idea to embed semantics into your element name (why do that when you've got attributes and elements that are better read by XML parsers).
The property definition element already contains the property type (cmis:propertyType) so embedding the type in the element name seems redundant. I recommend the property definition element names be changed to "propertyDefinition".
Jeff
--
This publicly archived list offers a means to provide input to the
OASIS Content Management Interoperability Services (CMIS) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: cmis-comment-subscribe@lists.oasis-open.org
Unsubscribe: cmis-comment-unsubscribe@lists.oasis-open.org
List help: cmis-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/cmis-comment/
Feedback License: http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
Committee: http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=cmis
|