NDR review for UnitsML

["Martin S. Weber" <martin.weber@nist.gov>]

Hello everybody, this is a review of the NDRs for UnitsML, which ones we break 
and which ones we might want to get rid of. As a reminder, you can get to the 
NDRs from the documents portion of our OASIS space, or from the site 
unitsml.nist.gov: 
http://unitsml.nist.gov/NDRs/NDRs-draft_for_UnitsML_schema_0.4.3.doc for the 
full version and 
http://unitsml.nist.gov/NDRs/NDRs-draft_for_UnitsML_schema_0.4.3-(rules_only).doc 
for the rules only.

Thanks to the QOD (Quality of Design) tool developed at the SIMA lab at the 
NIST we could also have some of these NDRs checked automatically. Also for 
future versions we got an account on that server in the meantime so we can 
rerun an NDR compliance test suite as need arises again.

The following is the list of NDRs we could check automatically, apply to our 
current situation (0.9.19 is no committee recommendation yet, or a standard) 
and which we follow (again, please open the NDR document in parallel, I'm just 
going to call the rules by their name mostly):

MDC2, ELD2, NMS1, VER3, VER6, VER7, GTD2, ELD6, ELD7, ATD7, ATD8, GXS4, GXS5, 
GXS7, GXS8, GXS10.

The following rules could be checked automatically but required a second 
manual scan:

GXS3 - made sure we are using complexTypes only in positions where it makes sense.

The following rules could be checked automatically and violations were 
encountered:

GTD1 (All types MUST be named): 4 violations:
  - enumeration of prefixes
  - enumeration of root units
  - enumeration "base" or "derived"
  - enumeration "base 10" or "base 2" ("10" or "2")
all of these are "inner types" and thus remained anonymous. They can be named 
though (doesn't bring added value, doesn't hurt either, so we can fix that).

ELD9 (The xsd:any element MUST NOT be used): 1 violation:
  - SymbolType: mixed content and xsd:any. ON PURPOSE! This doesn't mean the 
rule is bad. We are only breaking it in this specific place for a good reason, 
so we should document that we re deliberately breaking it here and why 
(unknown markup for the symbol goes here, too many to list).

The following rules were checked manually by me:

STA1, STA2 - check.

GNR4 (MUST NOT use acronyms except as published in appendix...)
We're using Units"ML", "WSDL", "URL" and "URI". Should be no problem 
publishing these in our appendix.

GNR5
no problem, see previous comment

GNR6 (defined acronyms MUST be used).
no problem. We are only using these few and never spell them out.

GNR7 (singular form for names)
We are breaking these in two instances: on the "RootUnits" element (and its 
type "RootUnitsType") as well as on "Conversions" (and its type 
"ConversionsType"). Now both of these are not per se (by their concept) 
plural, although for *practical* purposes they are (i.e. you could have a 
single root unit, but then you are just defining a power of a base unit, not 
some more complex/interesting derived unit -- also you could have a single 
conversion only and practically surely will have for some units, but then 
again, Conversion_s_ is the conversion container). IMHO we should document 
these and be done with it (no change necessary).

GNR8 (UpperCaseCamelCase for elements / types) - no violation

GNR9 (lowerCaseCamelCase for attributes) - no violation

GNR10 (acronyms in attributes upper case except if single word, then lower 
case) - no violation

GNR11 (acronyms upper case on elements) - no violation

Questionable rules:

UnitsML-GTD1 - imho equals GNR9 and can be dropped.
UnitsML-GTD2 - imho equals GNR8 and can be dropped.

RED1, ELD1, IND1, IND2, IND3: Basically do not apply to the scope of the 
UnitsML TC, governing instance documents of UnitsML. All of these should be 
dropped IMO:

RED1: our root element shall be instance document's root element. N/A! UnitsML 
is supposed to be embedded, also usage of portions of UnitsML only is a valid 
use-case of UnitsML!

IND1: UnitsML instance documents must validate to UnitsML schema? again, 
subportions of UnitsML is a valid use-case. Given we have every element 
global, also reordering of content is valid. Of course UnitsML is going to be 
a symbiont for other languages, and THEIR instance documents MUST validate, 
but this is not really our business.

IND2: the XML standard doesn't demand it. It's not really helpful either as 
the XML standard clearly defines how to deduce the character encoding. 
Finally, UnitsML again is no standalone language...

IND3: again ruling on UnitsML instance documents. We are not the ones to 
demand things from the languages who pick us up...

Remaining to be (manually, by me) checked:

- GXS1 (overall structure and alphabetized ordering): currently breaking it 
wildly, need to figure out how much of it we can/should stick to or if the 
rule should be dropped.

- GNR1 (valid english): don't think we'll have a problem there but I'll still 
make sure.

- ATD6 (xsd:schemaLocation MUST resolve): same as last one

Alright, that's it! I think we're doing quite fine with regard to the NDRs. 
Some should be dropped, our few exceptions should be documented / added to the 
appendix, and where we're breaking it for no good reason an easy fix is 
doable. The alphabetized rule (GXS1) still gives me some headache, but I'll 
detail that in a followup message.

Regards,
-Martin