Project

General

Profile

Task #4258

Story #2829: Structural changes to D1 Data Types schema for Version 2.0 release

Add Generic key/value element to Node

Added by Robert Waltz almost 11 years ago. Updated over 9 years ago.

Status:
Closed
Priority:
Normal
Assignee:
Ben Leinfelder
Category:
d1_schemas
Target version:
Start date:
2014-02-06
Due date:
% Done:

100%

Estimated time:
0.00 h
Milestone:
CCI-2.0
Product Version:
*
Story Points:
Sprint:

Description

(02:05:41 PM) robert: Matt, you want the product name of the MN software stack added into the node object?
(02:07:09 PM) matt: and version
(02:07:15 PM) matt: I think we need more node metadata in there
(02:07:23 PM) vieglais: good point.
(02:07:59 PM) matt: Dave and I had talked about adding a name/value pair field to the schema that would allow a variety of node properties to be added
(02:08:12 PM) robert: ok. I'll add it in to my list of v2 changes
(02:08:23 PM) matt: dave -- we talked about that when we were discussing the need for more node metadata for the dashboard

Something like some unformatted software stack version

The main problem is the uncontrolled nature of the key and value. If the key will result in machine actionable workflow, then we should have some list of controlled vocabulary/format that the tokens are validated against.
Maybe the property should have a type to indicate whether or not it is a controlled name and therefore machine actionable.

Metacat
2.5.0

My Crazy Software implementation
XMEN2.5.0-RELEASE

History

#1 Updated by Robert Waltz almost 11 years ago

  • Category set to d1_schemas
  • Assignee set to Robert Waltz

#2 Updated by Matthew Jones almost 11 years ago

I agree a controlled vocabulary would be great. An effective way to do this would be to type the key attribute as an xs:QName so that the values in the attribute can be typed and therefore validated by the XML parser. For example, the following snippet would use this technique:

Metacat
2.5.0

And the 'property' element would be based on a schema containing this ComplexType definition:

xs:complexContent


/xs:restriction
/xs:complexContent
/xs:complexType

Not sure if this would allow enough extensibility on the fly, as it might be just as restrictive as adding new elements to the node schema, unless we can find a way to modify the DataONENodeProperties schema without revising everything else. Might or might not work. Just a thought.

#3 Updated by Ben Leinfelder over 10 years ago

  • translation missing: en.field_remaining_hours set to 0.0
  • Status changed from New to Closed

Added Property type and Node can have 0..n of them. Includes a key, a type and, of course, the value.

#4 Updated by Robert Waltz over 10 years ago

  • Assignee changed from Robert Waltz to Ben Leinfelder
  • Estimated time set to 0.00

#5 Updated by Robert Waltz about 10 years ago

  • Target version set to CCI-2.0.0

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 14.8 MB)