RE: [unitsml] NDR review for UnitsML

["Linstrom, Peter" <peter.linstrom@nist.gov>]

Martin,

    Thank you for a very good review of UnitsML's compliance with
the NDRs previously specified. I think we should drop all of the
rules you identified as questionable, because they don't apply to
the use cases we expect for UnitsML. UBL is a much larger undertaking
than UnitsML with a different target audience; it is not unreasonable
that some rules developed for UBL would not be appropriate for
UnitsML.

    I would also consider dropping (or curtailing) compliance with
rule GSX1. It appears that UBL 1.0 is not fully in compliance with
this rule anyway. I can see the point of the rule for a language
like UBL which has a few dozen schema files, but since the UnitsML
schema is contained in a single file I think this type of rigid
formatting is less useful.

Peter Linstrom

======================================================
Peter J. Linstrom
(301) 975-5422
NIST, Chemical and Biochemical Reference Data Division
======================================================

> -----Original Message-----
> From: Martin S. Weber [mailto:martin.weber@nist.gov]
> Sent: Thursday, April 22, 2010 1:23 PM
> To: unitsml@lists.oasis-open.org
> Cc: Joseph.F.Solsky@usace.army.mil; Deborra J Zukowski
> Subject: [unitsml] NDR review for UnitsML
> 
> 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
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php