Skip to content.

TalkBMC

Sections
You are here: Home » Blogs » Van Wiles » Loose Coupling » Changes from CMDBf version 0.95 to 1.0

Changes from CMDBf version 0.95 to 1.0 Changes from CMDBf version 0.95 to 1.0

Document Actions
Summary of changes in CMDBf spec from 0.95 to 1.0 version

These things always take longer than I wish they would, but the CMDB Federation 1.0 spec is really now available for review on http://cmdbf.org.  It will stay there for an indefinite period of time, at least until it becomes an approved standard (a not-so-big assumption I hope).

I've been asked to summarize the changes from the 0.95 spec.  Here's a little guidance to understanding what changed:

  • The metaphor of selection was changed to align more with SQL.  The new metaphor is, for each template, select what you want in the results, and then apply constraints on the records and properties.  This is roughly comparable to "select column-names from table where value constraints apply".  In XML the structure in a template is either:
   <contentSelector> ?
<instanceIdConstraint> ?
<recordConstraint> *

or:

   <xpathExpression> *
  • The instanceId constraint was changed to allow a template to match multiple instances by instanceId.
  • A new <depthLimit> element was added to <relationshipTemplate> to allow variable depth on graph traversal.
  • New common properties of records, such as lastModified, were added to a <recordMetadata> element as the second child of each <record> element.
  • The <propertyValue> constraint may now be directed to <recordMetadata> properties using the @recordMetadata attribute.
  • The <record> @recordId attribute was moved to a child element of <recordMetadata> to allow for query on recordId.
  • The <xpathSelector> was replaced with <xpathExpression> child of itemTemplate and relationshipTemplate.  This allows greater control of XPath profiles and results.
  • The <propertySubsetDirective> element was replaced with <contentSelector> with <selectedRecordType> and <selectedProperty> children.
  • The <contentSelector> @matchedRecords attribute can now control whether all selected records are returned, or only the records that matched (the default).
  • The <propertyValue> record constraint may now be limited to selected record types.
  • The <dropDirective> element was replaced by @suppressFromResult attribute on itemTemplate and relationshipTemplate.  The functionality is the same.
  • The relationship is now considered a type of item.  This means two things - the "item" part of a relationship could be returned in a nodes list if it matches the constraints of an itemTemplate, and a relationship could be the source or target of another relationship.  There are some interesting use cases for this, but I'm not sure how widely implemented this will be.
  • "Section 6 - Service Metadata" was added.  This allows an MDR to publish the record types and optional query capabilities that are supported by the Query and/or Registration service.
  • "Section 7 - Secure, Reliable, Asynchronous Federation" was expanded to discuss issues and considerations to be addressed by the implementation, that are mostly beyond the scope of the CMDB Federation specification.
  • SOAP faults were defined for each operation.

_____
tags:
Thursday, October 25, 2007 in CMDB Federation  |  Permalink |  Comments (2)

Clarification

Posted by William Vambenepe at 2007-10-29 14:07
Just a clarification Van. In your blog entry you write "for each template, select what you want in the results, and then apply constraints on the records and properties" but this makes it sound like constraints can only apply to records that you want to be part of the result, not those that stay behind. This is not how I understand the specification. Can you please clarify what you mean and how you understand the specification on this point?

More specifically, imagine I have an instance with these two records (I hope the XML brackets make it when I post this comment):

<record1>
<foo>foovalue</foo>
</record1>
<record2>
<bar>barvalue</bar>
</record2>

And I have this itemTemplate:

<itemTemplate>
<contentSelector><selectedRecordType namespace="..."
localName="record1"/><contentSelector>
<recordConstraint><recordType namespace="..."
localName="record2"/></recordConstraint>
</itemTemplate>

In my interpretation of the spec, the instance would be selected but
only its "record1" record would be returned. Do you agree?
Van Wiles

Subscribe to Van's blog Subscribe to Van's blog

Bio & Writings

Email Alert: Van's Blog

Get an email alert when I publish a new blog! Enter your email address:

 

Powered by Plone

This site conforms to the following standards: