OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

obix message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Schema for obix contracts


Hi,

regarding the previous discussion on specifying a schema for the oBIX contracts I just want to double check if I understood the problem.
We have now the standard library with the standard obix contract definitions, expressed by example objects and here we want to have a machine-interpretable definition that can be checked by standard XML tools, right?

I think with XML schema this is not possible since it describes the generic oBIX object model and the contracts are the same as any other oBIX object. Any constraints on them can be just represented by having an according definition for human readers in the standard.

It would be desirable to have a formal description that can be used to verify automatically if an oBIX object adheres to a certain contract.

I think we have two options:
-) Schematron or something similar or
-) describing the oBIX meta model using MOF, which allows to define constraints on models (e.g. contracts) based on OCL

Schematron is a rule-based validation language for making assertions about the presence or absence of patterns in XML trees. It is a structural schema language expressed in XML using a small number of elements and XPath. (http://en.wikipedia.org/wiki/Schematron)

Using MOF to define the oBIX meta-model (the object model) which is currently expressed using the core schema would be a nice step towards a model-driven engineering approach. The different models could then be serialized using XMI, which would mean that contracts can be expressed based on XMI instead of plain XML example objects and then OCL could be used to express contraints.
(http://en.wikipedia.org/wiki/Meta-Object_Facility)

However, I am not really aware of how much industry support such technologies have and how mature they are.

Personally, I would prefer the MOF option since it seams to be more mature and opens the door to a variety of features such model driven engineering and code generation and maybe a standardized way to exchange oBIX contracts automatically using XMI.

Just my thoughts on the topic. But keep in mind, the complexity of such technologies and standards should not be underestimated, since I think one of the strengths of oBIX is its simplicity.

Best regards,
Markus







[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]