Category Archives: SML

Ctrl-Alt-Del on ISO/IEC SC 34?

Having been a alternate board member at WS-I, a committee co-chair at OASIS and at some point closely involved in W3C and DMTF working groups, I’ve had my share of dealing with standards organizations rules, bylaws and policies. All these organizations try to find a balance between openness/fairness on one end of the scale and efficiency/consistency/vision on the other. But all those are industry standard organizations and I have been spared the need to deal with the internals of the even more complex and bureaucratic “de jure” organizations like ISO/IEC. Those who follow the OOXML/ODF debate remember the often-alleged, never-denied (that I have seen) and ultimately unsuccesful attempt to stack the deck in favor of Microsoft’s OOXML by convincing a large number of new countries to join the vote at the last minute. Andy Updegrove now describes a probably unanticipated (let’s not be too cynical) consequence of this attempt: these new members don’t really understand or care about the work going on in SC 34 and their non-participation is preventing the group from making any progress due to the need to have a participation rate of at least 50% in the votes. And this is impacting many other specifications not related to OOXML (including, ironically, Schematron which is a dependency for the Microsoft-backed SML specification).

If this was OASIS, these countries would loose their voting status after failing to participate (if only by voting “abstain”) in a certain number of votes. But I don’t know if such minimum participation rules exist as a safety feature in ISO.

After the attempt to seize control, here is the halting of the work. Deletion is the logical next step in the ctrl-alt-del pattern that seems to be emerging…

Comments Off on Ctrl-Alt-Del on ISO/IEC SC 34?

Filed under Everything, ISO, ODF, OOXML, SML, Standards

Standards are good for customers… right?

Standards are good for customers. They avoid vendor lock-in. They protect the customer’s investment. Demanding standards compliance is a tool customers have to defend their interests when dealing with vendors. Right?

Well, in general yes. Except when standards become tools for vendors to attempt to confuse customers.

In the recent past, I have indirectly witnessed vendors liberally using the “standard” word and making claims of compliance with (and touting the need to conform to) specifications…

  • that have barely been submitted for standardization (SML),
  • that haven’t even been published in any form (CMDBF), or
  • that don’t even exist as a draft (CML – no link available, and for a reason).

Doesn’t something sound fishy when the logic goes through such self-negating statements as: “standards are good for you because they give you a choice of vendor. And we are the only vendor who supports standard X so you need to buy from us.” Especially when if it was true that the vendor in question implemented standard X, then it would not be their software that I would want to buy from them but their time machine.

All this doesn’t negate the fundamental usefulness of standards. And I don’t mean to attack the three specifications listed above either. They all have a very good potential to turn out to be useful. HP is fully engaged in the creation of all three (I am personally involved in authoring them, which is generally why wind of these exaggerated vendor claims eventually get back to me).

Vendors who are used to creating proprietary environments haven’t all changed their mind. They’ve sometimes just changed their rhetoric and updated their practices to play the standards game (changing the game itself in the process, and often not for the better). Over-eagerness should always arouse suspicion.

Comments Off on Standards are good for customers… right?

Filed under Business, CMDB Federation, CMDBf, CML, Everything, SML, Standards

SML submitted to W3C

The previously released SML 1.0 and SML-IF 1.0 specifications have been submitted to W3C for standardization (actually the submission happened on 2/28 but W3C has acknowledged it today). My guess is that the fact that this announcement comes on the same day that SCA 1.0 is released is not going to decrease the confusion between these efforts.

Comments Off on SML submitted to W3C

Filed under Everything, SML, Standards, Tech

SML 1.0 is out

After taking the form of two early drafts (versions 0.5 and 0.65), the SML specification has now reached v1.0, along with its sidekick the SML-IF specification. You can find both of them at serviceml.org. This is where the happy bunch that assembled to create these specs would normally part ways. Not quite true in this case since there is related work about to be tackled by a very similar set of people (more on this later), but at least we are not going to touch SML and SML-IF anymore. They are ready for submission to a standards body where further modifications will take place (more on this later too).

1 Comment

Filed under Everything, SML, Standards, Tech

SML versus the fat-bottomed specs

SML is, if I simplify, XSD augmented with Schematron. For those, like me, who aren’t fond of XSD, this is not very exciting… until you try to look at things in a different light. Instead of another spec that forces you towards the use of XSD (like WSDL), maybe the fact that SML uses XSD is your ticket *out* of XSD-hell. Let me explain.

I wrote above that I am not fond of XSD, and yet I see the value of having SML make use of it. Like it or not, many people and organizations have made heavy use of XSD to define well-known and reusable XML elements. And there is a lot of tooling (design time and runtime) for it. Breaking away from XSD altogether is possible (and advisable in many cases), but hard to do in places like systems management that have already invested heavily in using XSD.

The problem is that XSD is a document description language. It works well when the “document” abstraction is a good match. So, when I retrieve an XHTML page from a Web site, I want the paragraphs to be in the right order. The “document” abstraction is a good match. On the other hand, when I retrieve the configuration of a server, I don’t necessarily care if the description of the CPU comes before or after the description of the network card. I am still retrieving a document though (because XML forces this abstraction). But I don’t have the same requirements on its structure that I have on a document meant for publishing (like a Web page). For the non-publishing kind of interaction, a contract (a bullet list of things you can count on) is a better abstraction than a document.

XSD works better for the publishing kind of scenario, where you want to control all aspects of the document. It doesn’t work as well in situations where you just have some constraints that need to be met (e.g., the memory size must be a number) but other things are not important to you (order of some of the elements). As a result of XSD quirks, people often end up arbitrarily fixing the order of elements where it’s not needed (using xsd:sequence) and even have to introduce unneeded elements (to escape the dreaded UPA rule). And things become even worse when you have to extend and/or version existing XSD because of all the arbitrary constraints. Other metamodels like RDF avoid a lot of these problems by focusing on the assertion, rather than the document, as the base concept but this is a topic for another post.

One nice thing about the syntax constraints usually imposed by an XSD is that it makes the serialization of a piece of XML into a Java (or other language) more efficient. It doesn’t really matter semantically if the zip code is before or after the city name. In the US the zip code typically comes after (in postal addresses), in France it’s the contrary. And for this (unlike for the stupid MMDDYY date format, don’t get me started on this) you can make a case either way since in some places a zip code includes several cities and in others a city contains several zip codes. But whichever way you choose, you may be able to write a faster parser if you know in what order to expect them.

So I don’t mind at all having an XSD that describes a reusable type for elements that are very often used as an information atom, like an address (on the other hand, serializing an entire XML document into a Java object is often the wrong way to handle it).

By now you are getting an idea of what I want as an XML contract language. I want reusable elements that are small and potentially tightly defined (XSD definitions for a set of GEDs). And I want assertions that describe rules that a set of such elements need to obey in order to be valid as a unit per the contract. Which is where SML comes in. Because it provides a way to package XSD and Schematron, I can’t help thinking of it as a possible alternative to an all-XSD view of the world. If people have the discipline to only use the XSD part to describe small reusable elements and to rely on the XPath-driven Schematron constraints to provide the contract rules that tie these GEDs into a meaningful unit.

A few notes:

– I am fully aware (being part of it) that SML wasn’t created as a generic contract language for XML-based interaction, but as a desired state modeling language. The usage I am suggesting here is clearly a hack that abuses the syntax provided by SML (actually SML-IF). And I am not even sure that the SML-IF packaging would be an entirely convenient vehicle for this approach. I haven’t done the experimentation needed to validate that. It just seems to hit the ballpark of the requirements.

– I find it ironic that the approach to an XML contract language that I described above is already how many XML specs are defined in their human-readable section (at least in the SOAP world): a list of pseudo-XPath statements with a description of what to expect at the end of each one. But somehow at the bottom of each of these specs we get a huge XSD that imposes a lot of extra constraints that have no justification in the semantics of the spec. Rather than having a set of XPath-driven schematron statements that provide a machine-readable equivalent of the human-readable rules described used pseudo-XPath. Like the Queen song (almost) says “Fat bottomed specs you make the SOAPin world go dumb”.

1 Comment

Filed under Everything, SML, Standards, Tech

Come for the XML, stay for the desired-state approach

What would you think of programmers who switch from C to Java in order to be able to use Javadoc for interface documentation? On the one hand, if the benefits of Javadoc alone justify the effort to switch then why not? On the other hand, you can’t help thinking that it’s a pity that they don’t realize (and take advantage of) all the other improvements they are getting for switching to Java. Especially if they start to rewrite some of their existing C code in Java in a way that smells more like C than real Java. Wouldn’t you want to sit with them for a talk?

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’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’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.

Moving to SML because it is defined around XML documents is hard to justify. BTW, moving to SML because it’s based on XSD is even worse, as I’ll explain in the next post.

Comments Off on Come for the XML, stay for the desired-state approach

Filed under Desired State, Everything, SML, Standards, Tech

Is SML to CIM what WS is to RPC?

The question I hear most often when talking about SML, is how it relates to CIM. The easy part of the answer is to explain that SML is a metamodel, like MOF, not a set of model elements/classes like CIM. SML per se doesn’t define what a blade server or a three tier application looks like. So the question usually gets refined to comparing SML to MOF, or comparing an SML-based model to the CIM model. Is it a replacement, people want to know.

Well, you can look at it this way, but whether this is useful depends on your usage model. Does your usage model include a distinction between observed state and desired state? You can use SML to model the laptop in front of you, but if all you’re doing is reading/writing properties of the laptop directly you don’t get much out of using SML rather than CIM, definitely not enough to justify modifying an existing (and tested) manageability infrastructure. But if you change your interaction model towards one where there is more automation and intermediation between you and the resource (at the very least by validating the requested changes before effectuating them), then SML starts to provide additional value. The question is therefore more whether you would benefit from the extra expressiveness of constraints (through schematron) and the extra transformability/validation/extensibility (through the use of XML) that SML buys you. If you’re just going to assign specific values to specific properties then CIM is just as good. And of course keep in mind that a lot of work has already gone into defining the domain-specific semantics of many properties in CIM and that work should, to the extent possible, be leveraged. Either directly by using CIM where SML doesn’t provide additional value, or indirectly by carefully surfacing CIM-defined elements inside an SML model. Finally, CIM defines operations while SML doesn’t have such a concept. The most natural way to do a “start” using SML is not to invoke a “start” operation as it is in CIM, it is to request the configuration to be changed to a state in which the resource is started. In conclusion, there is a lot more to the “CIM versus SML” question than a direct replacement. Those who just look at ways to do syntactical translation between the two approaches will repeat the same errors that created (and still create) so many problems for those who saw Web services as just another way to do object to object RPC. The usage model (some would say the architecture) is what matters, not the syntax.

1 Comment

Filed under Everything, SML, Standards, Tech

SML feedback session

The public feedback session on SML will take place on September 12 in Mountain View. All are invited, but there is one of these pesky feedback agreements to sign. You can find the agreement at http://serviceml.org/. Once you’ve signed it, please send email to sml-feedback@external.cisco.com announcing your intention to come to the face to face meeting. Or you can directly email your feedback to that same address.

Comments Off on SML feedback session

Filed under Everything, SML, Standards

Announcing SML

BEA, BMC, Cisco, Dell, EMC, HP, IBM, Intel, Microsoft and Sun just published a new modeling specification called SML (Service Modeling Language). This is the next step in the ongoing drive towards more automation in the management of IT resources. The specification makes this possible by providing a more powerful way (using Schematron) to express system constraints in a machine-readable (and more importantly machine-actionable) way. It also has the advantage (being based on XSD) to align very well with XML document exchange protocols and the Web services infrastructure.

Here is the SML spec on the HP site. Very soon there will be an HTML version of the spec there in addition to the PDF. In addition, the serviceml.org Web site is a basic but vendor-neutral home for the spec.

Those familiar with the QuarterMaster work will see a lot of commonality and know that HP has a lot of experience to contribute in this domain: paper 1, paper 2 and paper 3.

This is an initial draft, not a final specification. The major hole in my mind at this time is the lack of support for versioning. Something to address soon.

There are many good things about this specification, but unfortunately not the name. Just for kicks, here are some better candidates:

  • ITSOK (IT Systems Operational Knowledge) “it’s ok”
  • ITSON (IT Systems Open Notation) “it’s on”
  • ITSUP (IT Systems Upkeep Profile) “it’s up”

Comments Off on Announcing SML

Filed under Everything, SML, Standards, Tech