[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [obix-xml] Schema
Gang, First, I'm sorry that schedule has been in conflict with the meetings as of late. I have been trying to keep-up offline on the progress. I like the proposed schema a great deal. Reviewing it, I have some questions/suggestions (and please forgive me: I know most of this was in the document as how they should be represented, so my comments are really related to the document as much as the schema representing it): <xs:element name="int" type="xs:long" /> [§2.5.2 int] We are saying here that "int" _is_ long, but xs:long is based on xs:integer (which is based on xs:decimal). When in fact, xs:int is _based_ on xs:long. I think we should lean toward the use of something similar to the name "long" if it's xs:long that we want to represent. --- <xs:element name="str" type="xs:string" /> [§2.5.4 str] Do we intend to allow CR/LF and tabs in these strings? If not, we should use xs:normalizedString instead (otherwise, it's fine to me). This question applies to parts like, for example: <xs:complexType name="UnitType"> <xs:attribute name="id" type="xs:string" /> <xs:sequence> <xs:element name="id" type="xs:string" /> <xs:element name="display" type="xs:string" /> <xs:element name="symbol" type="xs:string" /> These items seem like they should be restricted; and in these cases, typed to xs:token instead of xs:string, so that they have no leading/trailing spaces or double spaces, nor CR/LF and tabs. Strong typing will prevent UIs from breaking due to lack of such typing. --- <xs:element name="scale" type="xs:double" default="1" /> <xs:element name="offset" type="xs:double" default="0" /> [§2.6.8 units] These are typed as xs:double, but that means the interpreter needs to support 64-bit double-precision floating-point numbers. For scaling, even xs:decimal is more than we would likely ever need (18 digits), but I think it's better than xs:double. As an alternative, we could have a "multiplier" and "powerFactor" replace the "scale" element. Those could be typed as xs:byte, to prevent a scaling factor outside of -1.27E-125 and 1.27E+129. It amounts to the same, but decimals do not become an issue, and the computation becomes easy using the typical... rawValue = ((scaledValue / (multiplier * (10^powerFactor))) - offset) scaledValue = (multiplier * (10^powerFactor) * (rawValue + offset)) Also, the scaling then becomes limited so numbers like 3.16227766 cannot exist (multiplier of 1, powerFactor of 0.5, where rounding of numbers is needed to come close to the intended values). There are a few other xs:double types defined that we may wish to examine. --- [§2.7 Units] The "seven fundamental dimensions" may be insufficient to cover everything that needs to be covered in an building-control market. Measurement dimensions like turbidity cannot be represented by mole (mol), and candela (cd) without some very creative tables for substances. It would also serve us well to include percentage as a fundamental dimension, since it is used as though it were a unit unto itself. At the moment, I cannot recall others, but I will address them with you as the trickle to the forefront of my noggin. --- Great job on the schema. I think it does a great job of encapsulating the document. Talk to you all on the 1st, Jeremy ROBERTS, LONMARK International TEL: +1-215-918-1026 ________________________________________________________________ -----Original Message----- From: Brian Frank [mailto:bfrank@tridium.com] Sent: Friday, November 19, 2004 3:26 PM To: Aaron Hansen; obix-xml@lists.oasis-open.org Cc: Don.Delaurier@Edwards.spx.com; ganesh.markale@honeywell.com; Jeff.VanKeuren@Edwards.spx.com; kirkatcaba@sympatico.ca Subject: RE: [obix-xml] Schema I will try to go thru this bullet list the week after Thanksgiving and update the document accordingly. Great start Dave! -----Original Message----- From: Aaron Hansen Sent: Tuesday, November 16, 2004 2:31 PM To: obix-xml@lists.oasis-open.org Cc: Don.Delaurier@Edwards.spx.com; ganesh.markale@honeywell.com; Jeff.VanKeuren@Edwards.spx.com; kirkatcaba@sympatico.ca Subject: [obix-xml] Schema A great big thanks goes to Dave Richards of Trane for producing and taking ownership of the schema for the Sys service. He's done a great job! Here are some of his notes concerning the schema and specification: 1) Section 2.5.1: Why disallow "0" and "1"? Seems easier to just use xs:boolean than to restrict it. I did not do the restriction in my schema. 2) Section 2.6.8 should be called "unit" to be consistent with element name. Paragraph text should be changed as well. 3) Section 2.6.8 - last sentence should reference 2.7 rather than 2.6. 4) Section 3.2.6 - why is there a service element with nothing but an id element? Seems like we could eliminate one or the other. 5) Section 4.2.2 - wasn't sure exactly what the ext element does or how to accurately represent the fact that the result can be an ext from other namespaces. I made it accept any element from another namespace, which is not right. 6) Section 4.2.2 - children description should say "if the request..." not "is the request..." 7) Section 5.1.2 - can a write element have both a value and an object child? Seems like it could. Also, why is there no analog of the object/sub-object in the read service to avoid repeating full paths? 8) One issue with the schema is whether we want all types explicitly named or whether the anonymous types are OK. Some WSDL importers seem to have issues with nested anonymous types. 9) For the read result, do we want the generic <object> with the choice of value elements or do we want to create typed result objects? The typed objects would allow us to specify which facets are allowed for the various types. They would also allow a substitution group which is somewhat more flexible than the choice group. Dave and I agree that the simple data types shouldn't be top level elements. Recommendations?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]