Closed relu91 closed 7 months ago
Name | Link |
---|---|
Latest commit | e201b0d6558ceffd8b71b215cf04fd4112365d39 |
Latest deploy log | https://app.netlify.com/sites/wot-binding-templates/deploys/657866a4d95e480008bc2e32 |
Deploy Preview | https://deploy-preview-331--wot-binding-templates.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site configuration.
Looks good thanks! The rendering is broken somehow? Also, can you add https://www.w3.org/TR/2012/REC-xmlschema11-2-20120405/#hexBinary to express bit arrays?
Also in another PR, we should explain the mapping of the xsd types to what Modbus libraries would understand, i.e. saying that xsd:int
is signed integer 32 bit.
Also, we should have another PR where we explain how the Data Schema maps to the types in the form (and vice versa), i.e. having type:string
above in Data Schema requires xsd:string
in modv:type
value. We should do this at least for simple types
@relu91 will regenerate the ontology file to resolve conflicts and can just merge asynchronously.
talked with @egekorkan we can merge it now.
After the discussion in #293 this PR introduces three new terms to the modbus binding template:
modv:type
modv:mostSignificantByte
modv:mostSignificantWord
I did my best to explain the rationale behind the three new terms and provide a short example. About
modv:type
instead of introducing a new set of terms I decided to reuse XML Schema DataType but I tried to narrow them down to the list of this comment (let me know if I left something). I am not 100% sure about the design I chose for introducing this new property in the ontology, @mahdanoura if you can double-check it would be great. The rationale was that I needed a way to say that themodv:type
points to a valid XML Schema Data type among the ones we like. Not finding a class that covered all of them I created one and used a restriction. Let me know if it makes sense.