DataTypes Comments Section 8

8 Data Type Flavors

• 8.1 Flavor Concepts

1. The "SHALL NOT" in the introductory paragraph reads like a "meta-constraint". Is this here because applications can create constraints as well? If it is simply to state that none of the Flavors in this section of the specification are allowed to introduce new semantics and the like, wouldn't it just be simpler to not do as much? An application is compliant if it is compliant to this specification, and, if the specification is incorrectly written, (e.g. it adds "new semantics" to a data type), the application can't hardly be declared non-compliant if it follows the spec, can it? I'd really rather just see the paragraph say that "Flavors don't add new properties or set default values for properties" if it isn't an external requirement.
2. What does it mean to "add new semantics" to a data type. Isn't defining a "non-null boolean" adding semantics to "boolean"? Wouldn't the second sentence be sufficient?
3. P2 is a bit confusing - I kind of see where it is going, but maybe it could be clarified a bit.
4. (§ ) documents the property flavorId. - there's that mysterious "(§ )" again - it sure says a lot of things in this document...

• 8.2 Flavors of BL
• 8.3 Flavors of ED
  1. If we're going to reiterate the constraints in SHALL-ism's, we need to be consistent. The previous "SHALL" says that "Values conforming to the BN flavor SHALL NOT..", so shouldn't this say "Values conforming to a non-null ED.TEXT flavor SHALL..."?
  2. The reference to ST in the SHALL is a little misleading, as DOC doesn't have the additional attributes of ST
  3. 8.3.3 - ED.DOC.INLINE - same complaint on the SHALL's - will stop griping here, but they need to be fixed all the way through this section.
  4. 8.3.4 - just out of curiosity, is the intent to allow an embedded document as well? (This gets back to some potential confusion about ED in general and how the reference and the data are related...)
  5. 8.3.8 - "invariant (ED.STRUCTURED_TITLEx x) where x.nonNull ( ... (insert a space here)
• 8.4 Flavors of ST
  1. ST.SIMPLE - unless I'm missing something, this doesn't conform to most existing implementation technologies, as it still carries translations. Do we need a ST.REALLY.SIMPLE that constrains the character set to a couple of well known choices and doesn't allow translations?
• 8.5 Flavors of SC
  1. 8.5.1 The SHALL statement is completely opposite of the invariant. SHALL statements need some serious review in this area...
• 8.6 Flavors of CD
• 8.7 Flavors of TEL
  1. The definition of TEL is "TEL may be used to designate a retrievable resource such as a web page, a telephone number (voice, fax or some other resource mediated by telecommunication equipment), an e-mail address, or any other locatable resource that can be specified by a URL." Is the difference between TEL and TEL.URL an "MAY/SHALL issue?" This is particularly confusing as the chain is URL <-- TEL <-- TEL.URL
• 8.8 Flavors of EN
• 8.9 Flavors of INT
  1. Is the entity, "0" identified for integer? I recollect elsewhere the need to build a "zero.isZero" type thingie...
• 8.10 Flavors of PQ
• 8.11 Flavors of TS
• 8.12 Flavors of IVL
• 8.13 Flavors of URG
• 8.14 Flavors of GTS