<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: Is SML to CIM what WS is to RPC?</title>
	<atom:link href="http://stage.vambenepe.com/archives/11/feed" rel="self" type="application/rss+xml" />
	<link>http://stage.vambenepe.com/archives/11</link>
	<description>IT management in a changing IT world</description>
	<pubDate>Tue, 06 Jan 2009 07:29:02 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: William Vambenepe&#8217;s blog &#187; Blog Archive &#187; Come for the XML, stay for the desired-state approach</title>
		<link>http://stage.vambenepe.com/archives/11#comment-82</link>
		<dc:creator>William Vambenepe&#8217;s blog &#187; Blog Archive &#187; Come for the XML, stay for the desired-state approach</dc:creator>
		<pubDate>Tue, 16 Jan 2007 23:23:26 +0000</pubDate>
		<guid isPermaLink="false">http://stage.vambenepe.com/archives/11#comment-82</guid>
		<description>[...] Well, I am seeing early signs of this happening with SML. As I wrote earlier, the main difference between CIM and SML is that of usage model. Unlike CIM, SML is designed to enable desired-state management. That&#8217;s the real difference. But it also happens that SML is XML-based (and naturally compatible with document exchange types of interactions, be they Web Services or REST) while CIM is not (and its XML form is unusable in practice for anything other than RPC). And the difficulty of doing XML doc exchange with CIM happens to be a more immediate problem to many people than desired-state management. As a result, it is tempting to look at SML as a solution to CIM&#8217;s lack of XML friendliness. But moving to SML for this reason, while keeping the same level of granularity and the same usage model, is just like moving from C to Java for the Javadoc. [...]</description>
		<content:encoded><![CDATA[<p>[...] Well, I am seeing early signs of this happening with SML. As I wrote earlier, the main difference between CIM and SML is that of usage model. Unlike CIM, SML is designed to enable desired-state management. That&#8217;s the real difference. But it also happens that SML is XML-based (and naturally compatible with document exchange types of interactions, be they Web Services or REST) while CIM is not (and its XML form is unusable in practice for anything other than RPC). And the difficulty of doing XML doc exchange with CIM happens to be a more immediate problem to many people than desired-state management. As a result, it is tempting to look at SML as a solution to CIM&#8217;s lack of XML friendliness. But moving to SML for this reason, while keeping the same level of granularity and the same usage model, is just like moving from C to Java for the Javadoc. [...]</p>
]]></content:encoded>
	</item>
</channel>
</rss>
