| SubmissionsW3C is pleased to receive the Service Modeling Language (SML) Submission from BEA, CA, Cisco, EMC (Documentum), HP, IBM, Intel, Microsoft and Sun Microsystems.
This submission defines the Service Modeling Language (SML), which is intended, according to its abstract, to be used to model complex IT services and systems, including their structure, constraints, policies, and best practices.
W3C normally refrains from standardizing XML vocabularies for specific application areas, unless they have foundational character (e.g. XML Schema, XSLT) or very wide application (HTML, MathML). Vocabularies for other areas are better standardized in other fora. But SML is not a conventional XML vocabulary. It defines no elements or attributes with any semantics specifically related to IT services or systems. Instead, it is at once a profile and an extension of XML Schema 1.0 and Schematron: an SML model (description of a system) consists of
SML can thus be interpreted as providing, at the same time, (a) a layered extension of XML Schema, which allows validation to enforce structural and referential integrity constraints within a single XML document but also across multiple documents, and (b) a subset or profile of XML Schema 1.0.
It thus relates very closely to the work of the W3C XML Schema Working Group, in the XML Activity, and slightly less closely to that of various groups in the Semantic Web Activity, in particular those responsible for RDF Schema (first the RDF Schema Working Group, later the RDF Core Working Group). The remainder of this comment summarizes the salient features of the profile of and extensions to XML Schema 1.0 provided by SML, describes their relation to the work of the XML Schema Working Group and the Semantic Web Activity, and mentions some possible next steps for work in this area.
SML restricts the use of XML Schema 1.0 in several ways.
The use of xs:redefine is forbidden.
(Note: in this comment, qualified names with the prefix
xs are used to denote names in the XML Schema
namespace.)
The rationale given for this restriction is that
xs:redefine does not guarantee that the new
definition of a schema component is compatible with the old one;
redefinition of schema components may break existing components.
Unqualified local elements are prohibited in SML.
This helps avoid name conflicts among local elements and promotes “a consistent naming approach”.
Each schema document in an SML model must specify a target namespace.
This avoids problems with the interpretation of unqualified names in XPath 1.0 expressions.
To these reviewers, these restrictions seem to illustrate a certain tension in the document between viewing SML as a domain-specific language for describing IT systems and viewing it as a meta-language which specifies how to define a domain-specific language. All of the restrictions are defensible as a matter of stylistic preference, and all are recommended by at least some authorities on schema usage. But all appear potentially problematic in the specification of a meta-language, which for the most part should leave questions of style to the users of the meta-language.
SML defines type, attributes, and elements in the SML namespace, all of which can be used in XML Schema 1.0 schema documents. A complete listing of these is given in section 7 of the SML specification.
The most important extensions are to support inter-document
validity constraints: the sml:reference type, used for
inter-document references; the smlfn:deref() extension
function for XPath 1.0, which finds reference elements and
retrieves the nodes they refer to; and multi-document analogues
to the intra-document identity constraints of XML Schema 1.0.
At first glance, it may appear curious that the extension
of XML Schema's identity constraints goes as far as it does.
Surely, if all of the student records are in a Students.xml
document, the uniqueness or key constraints on student records
should be declared in the schema used by Students.xml,
and all that's needed in other documents is an extension of
the keyref constraint, which allows a keyref to point to a key
defined in another document.
For situations in which the keyed records are indeed all in the same document, it might be desirable for SML's sml:keyref construct to integrate more tightly and naturally with an XSD 1.0 key constraint in the target document. But for situations in which each student record (for example) is a different XML document, the uniqueness and key requirements across the entire collection require some treatment like that offered by SML.
Viewed as a schema language, SML embodies a critique of XML Schema 1.0 from a particular angle. The profile of XML Schema effectively provides a list of schema constructs which have proven problematic for users and software developers at least in the context of SML. The extensions to XML Schema 1.0 may be interpreted as a request for enhancement, together with a design showing a possible realization of the enhancement.
But SML is properly viewed not as a schema language competing with XML Schema 1.0, nor as a revision of XML Schema 1.0, but as a layer of inter-document constraints designed to be used on top of XML Schema.
The key contribution of SML to validation lies in its handling of inter-document constraints, which can and should be layered on top of the single-document validation of XML Schema or other schema languages. Any work on SML as a language for cross-document validation should be performed in regular and extensive consultation with the XML Schema Working Group, but should almost certainly be described in a separate specification, probably prepared by a different Working Group.
It should be noted that the addition of assertions to XML Schema 1.1 may make at least some uses of Schematron unnecessary for SML. That area presents a possible incompatibility between SML and existing W3C work.
Many groups in the Semantic Web Activity have an interest in data integration from multiple sources. The validation of inter-document references, however, is not of primary importance or interest in the Semantic Web context. More interest attaches to the imposition of constraints on the RDF graph of the information in the documents being validated, but this has no necessary relation to the original representation of the information in one or several XML documents, or to inter-document references.
Semantic Web technologies rely on the URI as the atomic unit of naming and identity; they will tend to be less useful for manipulating information about SML models which use end-point references (EPRs) instead of or in addition to URIs.
For that reason, it is not clear that any groups in the Semantic Web Activity will take an active interest in SML, but any further work on SML should certainly solicit input from the Semantic Web Activity.
Section 3.3 of SML provides two mechanisms for reference schemes, namely Uniform Resource Identifiers (URIs) and endpoint references (EPRs). It should be noted that the Web Services Addressing specification does not define equivalence between two EPRs, and specifies that “using abstract properties of an EPR other than [destination] to identify resources is contrary to the Web Services Addressing recommendation”. The example in section 3.3.2 (EPR Scheme) therefore seems misleading in its use of EPR reference parameters. We believe that using reference parameters in an EPR that is included in an SML 1.0 document should be avoided.
If further work is done on these specifications, some notes on the technical content may be in order.
sml:targetRequired
attribute to be specifiable only in a schema document. Would it
not be worthwhile to allow this to be under dynamic control,
perhaps as an option to the SML model validator? The analogy
with SQL referential integrity constraints suggests that
dynamic control might be both necessary and convenient.sml:ref type at some point.
There are two ways this work can progress within W3C: recharter the existing XML Schema WG to undertake it, starting from this submission, or form a separate Working Group to work on SML as a layered approach to multi-document validation compatible with and relying upon XML Schema as the lower layer, with this submission as the starting point for a requirements document. On balance the second option seems preferable.
In either case the XML Schema Working Group should look carefully at the experience of the SML developers and consider ways in which their input can improve future versions of XML Schema.
Any work on SML as a language for cross-document validation should be performed in regular and extensive consultation with the XML Schema Working Group.
Disclaimer: Placing a Submission on a Working Group agenda does not imply endorsement by either the W3C Staff or the participants of the Working Group, nor does it guarantee that the Working Group will agree to take any specific action on a Submission.