Description: |
General. Many examples are missing the source attribute on the appinfo element. Or have no surrounding annotation/
appinfo syntax at all.
General. Inconsistent capitalisation of first word in bullets of lists. Suggest UC, unless the word is a property/
attribute name.
General. Consistent formatting for table column headers needs to be applied. Suggest unbolded italics.
General. Need numbering of all tables and all figures.
General. Several instances of 'dfdl' that should be 'DFDL'. And 'Dfdl' that should be 'dfdl'.
General. Although dfdl:encoding enums are case insensitive, we should stick to UC throughout in examples.
General. Several typos of 'lentgh'
General. Remove the remaining OMG/CAM references from property descriptions. Supply an appendix that maps between the
two.
1.2. "an information set" x 2
1.2. "IBM’s WebSphere Business Integrator Message Broker" needs to drop the BI.
1.2. XSDL reference. Should say 1.0 and provide reference to spec.
1.2.1. Text example - the separator property should be ",%WSP;" or the space removed from the example.
1.3. "There are a couple of..." is better as "There are two..."
1.4. "DFDL is capable of describing a wide variety of textual data formats such as HL7, X12, SWIFT" - add sentence that
introduces the concept of syntax markup.
2. I agree with the existing comment that the RFC2119 key words should be upper case.
2.4. "Note that occurs checking, i.e., non-conformance with minOccurs whether parsing or unparsing is a processing error
, not a validation error". Removing maxOccurs from this sentence has broken it. Suggest dropping the "occurs checking,
i.e."
3. Array, Array Element etc definitions don't take into account maxOccurs = "unbounded".
4. Section TBD Information Items should be a ref to 4.1.2.
4.1.1. [root] member. Definition should remove "global".
5.1. Resolve "(TBD: need means for an implementation to indicate it is using non-standard extensions?)"
5.2. Is use of the word 'attribute' correct?
5.2.1. "To determine the maximum acceptable number of occurrences of an array both if validating when parsing and
unparsing" - the insertion of "if validating" is in the wrong place in the sentence.
5.2.3. Resolve TBD.
5.2.6. I don't think this section should be here.
6.2. Given that the description talks about annotation points, suggest a 3rd column listing the allowable annotation
points for each annotation. Also 2nd column should have a link to relevant section 7 sub-section.
6.2. Blank row.
6.2. format. Remove reference to xs:complexType.
6.3.1. WSP = "Single whitespace", WSP* = "Optional whitespaces" and WSP+ = "Whitespaces".
6.3.1. For brevity and maintainability, can we avoid listing the set of white space characters three times?
6.3.1. Should ES be "empty string" rather than "empty space" ? The phrase 'empty string' is used throughout, 'empty
space' is used once to mean something different (see fill byte).
7.1. Several instances of 'object' instead of 'component'.
7.1. table entry for xs:complexType is incorrect - should say xs:schema.
7.1. New para about the schema level dfdl:format annotation should start "A dfdl:format ..."
7.1.x. In these sub-sections the term 'format block' is used - that is an obsolete term.
7.1.1. Replace "... on a complex type." with "...on a format annotation on the xs:schema element" x 2
7.1.3. The example uses dfdl:format and xs:complexType.
7.1.3. Can I use a selector on a dfdl:property element? I can see a use case but I suggest we disallow this for now -
it would make tooling difficult as it means element/attribute form is no longer an arbitrary decision.
7.2. Talks about 'active' annotation. You should introduce that concept in 7.1.3 (eg, in use 'active' & 'inactive'
instead of 'used' & 'ignored').
7.2. The 'active' annotation sentence should start "After any selectors have been applied, ...". And say that it is an
error otherwise. I think this same senetence also applies to the other named annotations.
7.3.1. Phrase last para in active/inactive terms.
7.9. Formatting has gone awry.
7.9. Is there a difference between "not overpunched" and "unpunched" ?
7.10.1. Bolding looks wrong.
7.12.2. The namespace column is wrong - 'dfdl' is not a namespace, it is a prefix.
7.12.2. Need an example of their use.
7.12.2. State it is a scheme definition error if dfdl:defineVariable is used with DFDL namspace.
7.12.2. Remove leading space from ' ieee'.
8. Reference to XPath 2.0 needed.
8.5.3. You missed an occurrence of dfdl:length (because there's a space after the colon)
10.1. "...and respectively." Remove "and".
10.2. Wording needs changing. I read this as the selector itself could be defaulted from a dfdl:format.
10.4. Divide rule 3 into a) and b) for clarity.
11.2. A couple of TBDs to resolve.
11.3. Definition of complexElement appears twice in table.
13. Footnote 5. Resolve TBD.
13. Footnotes 4 & 6. A better example than selectors is the use of the pre-defined variables that match these properties
.
14.3. We have a reader look ahead problem here. Once we start talking about implicit lengths and other length rules, we
have to talk about representation, which we haven't covered yet.
14.3.2. I won't comment on this as Tim is thinking about the different cases, and it will come up on a WG call soon.
14.3.3. Avoid the word 'unfortunately'.
14.3.3. Properties on packed4 are wrong.
14.3.3. "hidden prefix element" - could be confused with DFDL use of hidden.
14.3.4. There are type/rep combinations where lengthKind="implicit" is not allowed - so saying that 'pattern' is
replaced by 'implicit' on unparsing does not work.
15. FloatFormat (in table)
15. Should the Logical Type column values have xs: prefix, like the earlier text ?
15.4. textNumberFormatRef. Gone badly wrong. Embeds an entire section 15.4.1. Repetition with section 7.9. Formatting
gone awry. Bullets aren't used in other properties. Repetition with section 15.4.2.
15.5. Similar problem to 15.4 textNumberFormatRef.
15.5.1/2. Last sentence. By definition an unsigned number can not be positive :)
15.10. binaryCalendarRep. binaryPackedSignCodes is not used when BCD. Also broken ref.
15.11. I don't think there should be any properties in this section. Everything should have been described in 14.3. (15
.11 is wrong anyway - it needs to mention xs:maxLength).
16.2. I'm not sure that scannability in this constant encoding sense is necessary for patterns. I can create a regular
expression that extracts all characters up to hex value xXX or all characters up to xYY, thereby treating the content as
an encoding in-sensitive black box.
17.1. "Nested choices recursively" - we don't support recursion, so whatever this is describing must use different
language.
23. Missing new property dfdl:truncateKnownLengthString.
|