[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [obix] Groups - oBIX 1.1 XML Schema: NIEM Refactoring WD03 uploaded
Hi Chris,
1. Since the benefits of using NIEM are rather limited I suggest to not apply it. 2. I have identified a major problem in your schema which I have also faced initially: This constructs: <xs:element name="Obj" type="obix:ObjType"/> <xs:complexType name="ObjType"> <xs:complexContent> <xs:extension base="ObixComplexType"> <xs:choice> <xs:element ref="Obj"/> <xs:element ref="Bool"/> <xs:element ref="Int"/> <xs:element ref="Real"/> <xs:element ref="Str"/> <xs:element ref="Enum"/> <xs:element ref="Abstime"/> <xs:element ref="Reltime"/> <xs:element ref="Date"/> <xs:element ref="Time"/> <xs:element ref="Uri"/> <xs:element ref="List"/> <xs:element ref="Ref"/> <xs:element ref="Err"/> <xs:element ref="Op"/> <xs:element ref="Feed"/> </xs:choice> </xs:extension> </xs:complexContent> </xs:complexType> leads to the situation that if you want to transfer for example an bool object you have to use the following XML fragment: <Obj> <Bool val="true"/> </Obj> 3. The problem The issue is the xs:choice element that is a complex content of the ObjType type which is refered by the Obj element. First I tried to use XML schema inheritance to map the oBIX object model. But the problem are the value object types. They have the "val" attribute and it changes depending on the concrete type. The change of a property type in a sub class is not possible in Java, so this is not working if we have the Val type as base class. If we leave Val type away it is possible, however the use of inheritance leads to an unconvinient encoding, for example by JAX-WS. This was the reason why I modeled every oBIX value object type as separate complex type and used this xs:group mechanism with xs:choice to realize this kind of object inheritance. The issue now is that we need a wrapper element since this choice can only be used for content of an element and not for the element type itself. 4. The solution If we introduce a response element within the wsdl that acts as a wrapper for the xs:choice construct the whole thing works. Unfortunately this breaks the existing draft. But I think the change is not so dramatic. 5. Child nodes not supported Your current schema does not support child nodes. This need to be supported for all none base value object types and especially for list types. 6. WSDL verification You can verify your WSDL using tools like SOAP UI (www.soapui.org). It allows you to generate mocked SOAP web services and test requests which I found rather helpful. I will upload my schema together with the WSDL (obix_1.1_schema_mj) as support for fixing the above mentioned issues. But after looking into NIEM I would suggest not to use it since the XSD gets more complex and unreadable through it. The provided WSDLs are working in our proof of concept implemenation and you can have a look on possible SOAP interaction through Java here: https://code.google.com/p/iotsys/wiki/SOAPinteraction - it is illustrated how to read the about object or to query a temperature history. Bests Markus Am 14.06.2013 15:14, schrieb Chris Bogen: Submitter's message -- Dipl.-Ing. Markus Jung Research Assistant mjung@auto.tuwien.ac.at Tel. +43 1 58801-18322 Fax +43 1 58801-18391 Institute of Computer Aided Automation Treitlstr. 1-3/4. Stock/E183-1 Vienna University of Technology |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]