Standards » Data Area » DFDL WG

Section 23.5.4: Incorrect examples.

dfdl:hexBinary (-2084) is the hexBinary value "F7FF"
This should be "F7DC"

dfdl:hexBinary (208) is the hexBinary value "D0"
This should be "00D0" as the arg is treated as signed so xs:short.
Perhaps the two examples for 208 should become:
dfdl:hexBinary (208) is the hexBinary value "00D0"
dfdl:hexBinary (xs:unsignedByte(208)) is the hexBinary value "D0"

dfdl:choiceChoiceBranchKey appears a couple of times

a) Broken links in sections 6.3.1.4 and 33.1; should be to Table 2 in section 6.3.1.2.
b) Missing bullets in section 12.3.6 (endOfparent) when listing what a simple element must have one of.
c) Bullet indentation in section 22 not correct for dfdl:textNumberRounding and dfdl:calendarPatternKind

Section 16.4 "Uncertaintyfor"

Section 14.2. Errors in paragraph:

"However, the WSP* entity cannot appear on its own as one of the string literals in the list when determining the length of a component by scanning for delimiters, , and it is a schema definition error otherwise. delimiters"

Correct as follows - sentence is split into a bullet and a sentence that applies to all bullets, to match words for terminator:

"• The WSP* entity cannot appear on its own as one of the string literals in the list when the parser is determining the length of a component by scanning for delimiters.

If the above rules are not followed it is a schema definition error."

Sentence: "However, many statically type-correct values will still not be convertible to the result type.It is a processing error if the supplied argument value is not convertible to the constructed type."

Space needed before "It".

Look at the reference notes/footnotes at the end of the HTML version of the spec. You'll see some odd spacing, but also there's at least one note that uses a different font size.

dfdl:choiceKind should be dfdl:choiceLengthKind in section 12.3.6

The property choiceChoiceBranchKey appears in a number of places and should be choiceBranchKey.

Section 15.1.2 the second sentence ends with ",." should be "."

In section 15, in the description of choiceBranchKey, there is a font inconsistency in the 4th paragraph. Should be consistent with the rest of the description.

In sections 31.2, 31.3, 31.4 the examples specify dfdl:escapeEscapeCharacter="%". Should be "%%" (with a footnote explaining that % needs escaping when used as a literal character in DFDL properties).

Section 14.2.1 requires that 'Trailing or Actually Trailing' definition needs 'Trailing or Actually Trailing' to be in bold and italics.

9.3.1.1 Known-to-exist
Last 4 lines of this section should be a numbered list.

Examples in the spec use fn:string(...) function call.

However, per section 23, the xs:string(...) function is supported, but not fn:string(...).

I am not sure the difference between the two functions, but the namespace prefix matters, and we need to consistently use xs:string(...).

So change all "fn:string(" to "xs:string(".

There is a handful of such occurrences.

In description of encodingErrorPolicy property, a opening single-quote is missing in sentence:

"If error' then a processing error occurs."

Section 13.7.1.1 has dfdl:binaryVirtualDecimalPoint - should be dfdl:binaryDecimalVirtualPoint.

Spec has "the dfdl:separatorPosition of the sequence is 'postFix'"

Should be all lower case 'postfix'.

Conforming DFDL v1.0 processors must accept at least 'UTF-8'', 'UTF-16', 'UTF-16BE', 'UTF-16LE', 'ASCII', and 'ISO-8859-1' as encoding names.

Notice the double quote after UTF-8. I believe it should be a single quote.

Section 10 first page introductory material ends with this paragraph:

The property description defines which schema component that the property may be specified on.
In addition all the DFDL properties may be specified on a dfdl:format annotation.

The last sentence is wrong I think. You cannot put dfdl:inputValueCalc and dfdl:outputValueCalc on dfdl:format. There are a few others also I think.
I think the last sentence should say "most" not "all" as in "In addition most DFDL properties may be specified on a dfdl:format annotation"

Section 9.3.1.1
Delete phrase "...this of course implies that....". Note that there is already a correction to create numbered bullets of 3 sentences. The sentence containing this phrase will be bullet #3 of that list.

the example in section 12.3.4 has a typo. It says:

dfdl:prefixIncludesPrefixLength="false"

it should be:

dfdl:prefixIncludesPrefixLength="no"

Section 12.3.3 Table 18.

"maxlength" should be "maxLength" with capital L.

Section 12.2

Description of initiator property, the language referring to DFDL String Literals is not specific enough, leaving it ambiguous (somewhat) as to whether the literals are obeying those specific rules of syntax or not.

The first sentence says "alternative literal strings". It can be improved to say "...alternative DFDL string literals, one of which..."

The fourth paragraph should say "...only certain kinds of DFDL string literal syntax."

In section 6.3.1.4

"The syntax is in Error! Reference source not found. above."

Section 33.1

"...using the grammar in Error! Reference source not found. of Section 6.3.1 ..."

Section 12.2

initiator property

refers to byte value entities (%#r)

should use complete notation %#rXX;

Section 14 For property initiatedContent

The sentence "If the child is optional then it is deemed to have been found when its initiator has been found." should use consistent terminology of "known to exist" as follows "If the child is optional then it is known to exist when its initiator is found."

Section 15 as well, also for initiatedContent

"The branch is deemed to have been found when its initiator has been found." replace "The branch is known to exist when its initiator is found."

Section 14.2.1 The definition for "Trailing or Actually Trailing" should use bold-italic to match other definitions in that section.

In the description of textStandardBase property, it uses the name textNumberBase instead of textStandardBase

************************************
All prior updates above have been edited into the latest draft spec.

In the phrase "There are dfdl:asserts with failureType 'processingError' on the component and all their expressions evaluate to true or their regular expression patterns match,"

To clarify, should reword as "When there are dfdl:assert statements on the component having failureType 'processingError', their expressions evaluate to true or regular expressions match."

- 2.2. There are several uses of 'SDE' in the spec, but no definition of the acronym 'SDE'. Either define SDE here, or expand each use in full. Also noted inconsistent capitalisation of 'schema definition error'.

- 4.1.2. Should the casing of [datatype] be [dataType] for consistency with [dataValue]? Affects picture also.

- 9.2 Typo in table - NIlLogicalValue

- 9.2.5 "if dfdl:nilValue is %ES; or %WSP*; on its own is a literal nil value" - doesn't read right.

- 9.3.2. Typo ComplexContnet

- 9.4.2.3. "A complex element can parse, by recursive descent, and construct a complex element in the Infoset containing a single child element." - add the bold words.

- 11. Section numbering has somehow got applied to the deleted paragraphs in 11.1, so what was 11.2 is now 11.17, etc.

- 11.2.1.1. Typo 'Implementations' - should be lower case.

- 12.2. emptyValueDelimiterPolicy. "when the parent xs:sequence has dfdl:initiatedContent 'yes'". I think that should be "when the parent group has dfdl:initiatedContent 'yes'" to include choice.

- 14.2.1. "The dfdl:occursCountKind of the element" has lost its bullet.

- 14.2.2. Blank line between paras 4 & 5.

- 16. occursStopvalue. "dfdl:stopValue".

- 16.1.x. "no occurrences looked for" reads better as "no occurrences are looked for"

- 21. The deleted paragraph is an example of issuing warnings, not an example about bi-di text. It should be re-instated using a different property as the example.

******************************************************
All updates above have been incorporated into r11 of the v1.0.5 spec.

Section 14.2.

See "Non-Positional Sequence" - The fonts are not right. Bold part is not, text part is bold.

Detected looking at an HTML version of the revised spec.

updates prior to this have been integrated

The new table in section 23.5.5 does not spread to width of the browser window viewed in the HTML version of the spec.

It must have some different MS-word properties that are making it behave differently when converted to HTML.

In the HTML version, there is an empty comment bubble link in 23.5.5. It comes through as number [7] though others come through with author initials like [MJB2].

In 23.4, the Link to reference [Walmsley] does not work. Might have to turn off change tracking to get it to work properly then turn back on.

Phrase "then we have a circular deadlock."

Avoid "we". should be "then a circular deadlock occurs."

In the HTML version of the spec. (maybe others also)

23.5.2.4 the functions hours-from-time, minutes-from-time, seconds-from-time are underlined. Probably left over from MS-Word deciding they look like URLs due to the "fn:" on the front.

Remove underline. Match style of other function names.

In HTML version.

Table 59 Special Constructor for xs:dateTime

Table does not spread across width of window like other property tables do.

HTML version section 23.4

At the end of the section, the numbered list of Notes, number 5 there's something odd about the indenting. May be due to change tracking or may not. Revisit formatting.

HTML version Section 23.4 Table 57

The "::=" for IntersectExceptExpr is not aligned vertically with the others.

HTML version, Section 16.6

Excess blank lines between paragraphs.

Section 15 Table 52

We don't use tables like this in other places to introduce terminology. We use

Bold Italic - Normal text

Make consistent with other term definitions.

HTML Version Section 14.3.2.2

Heading for "Sort the Temporary Infoset"

Suggest adding "Step 1: " as prefix of the heading.
Similarly add "Step 2: " as prefix of the next heading "Check Scalar Elements and Validate"

There may be extra blank lines in this section as well.

HTML version, section 14.2.2 Table 47

This table is somehow too wide for the window, no matter how wide or narrow the window is. So you get a horizontal scroll bar so you can see the right edge.

Table 48 below it, does not have this problem.

Make table 47 behave like 48.

HTML version Section 13.11.1

Below table 40 The cross-link reference [ICUDateTime] appears twice, and there is also some whitespace extra blank lines or something here.

HTML version section 13.6.2

First two bullets in thi section are different from the next 4. Make consistent.

Table 33 Section 13.6.1.1 Columns are odd widths when table is streched wide for a wide window. The first column for "Data representation" is excessively wide.

Also "Data representation" should have capital R for Representation.

Section 13.5 - extra blank lines before this heading at end of prior section.

Section 13.2.1 Bullets in 3rd paragraph are different from rest of spec. make consistent. Also, in description of escapeCharacterPolicy - bulleted lists have whitespace lines before first bullet - inconsistent formatting.

Also table 27. First column excessively wide. Contrast to table 26 where the first column is sized to fit the longest property name. Similar problem with table 29.

Table 29 caption begins with "13.4" which is confusing. Other table captions do not have section numbers in them like this. And this section number is wrong anyway, remove.

Tables 11 (maybe), 12, 15, 16, 17, 19, 21, 24, 25(maybe), 31, 35, 36, 38, 39, 42, 43, 45, 46, 49 (maybe), 53, 55, 60, 63, 64, 66, 67, 69 - again first column too wide. Should be sized to width of longest property name.

Table 77 In section 34.4.6, does not stretch to width of window. It looks good as is, and would not look as good stretched, but... consistency with other tables is more important. Same thing table 78, 79.

Section 13.2.1.1 Bullet style wrong.

Section 23.4 Table 57 - too wide for margins resulting in horizontal scroll bar.

Section 9.5 first numbered list is goofed up. May be change-tracking interaction. Looks like number 2 has no text, and number 1 has two lines.

Section 2.7 Inconsistent sub bullets

Section 2.6 All sorts of inconsistent bullets. Uses § as a bullet. Also tiny dots, open circle dots, etc. Standardize.

Section 1 - inconsistent tiny-dot bullets.

Section 3 under Variable-Width Character Encoding - inconsistent tiny-dot bullets.

Section 4.5 lettered items a) b) c) are not indented. These should be indented paragraphs with hanging indent. Like numbered list, but selecting letter-style markers not numeric.

Section 5 tiny-dot bullet below figure 3.
Sections 5.2.3, 5.2.4, - more tiny-dot bullets
Section 7.6 - inconsistent hyphen bullets. Also, wrong font at last sentence. Is Bold, but should be plain text, except that section cross references have bolding by nature of being cross refs.

Section 8.3 After rule 7. The next sentence begins with quotation marks "Applicable" which is funny to the eye.
Add the word "The" at start of sentence so it looks better.

In general: Many section headings have inconsistent blank lines before them. Remove all manual extra blank lines and fix heading spacing in heading styles.

Section 11 encoding property - tiny-dot bullets. byteOrder spurious blank line and maybe "-" before "Annotation" on last line.

Section 11.2.1.1 Inconsistent indenting of lettered list items.

Section 12.1.2 introduces term "textual data". Use consistent form. Initial-caps Bold-italic on left, hyphen, then definition. Also, probably this definition goes in the Glossary, though we may want to repeat it here.

Section 12.2 initiator - tinydot bullets. Last of which is bolded text incorrectly.

(It is possible the bolding has something to do with change tracking?)

emptyValueDelimiterPolicy Look for spurious hyphen before "It is a Schema Definition Error". Might be change track artifact where blank line was deleted.

Section 12.3.2, 12.3.2, 12.3.6 have Tiny-dot bullets.

TBD: Some cross references appear to be made bold. Others are plain text. Some do not work as hyperlinks to navigate. E.g.,
In 12.3.7.2.3 and the next several sections at that same depth there are links (e.g. to 13.7) which do not hyperlink.

Section 13.6 textNumberPadCharacter has tinydot bullets as does textStandardDecimalSeparator, textStandardZeroRep,
textZonedSignStyle needs bullets to introduce the 3 value descriptions. It's too hard to read otherwise.

Section 13.13 binaryCalendarRep - bullets to introduce the descriptions of the values would make more readable. Probably same for binaryNumberRep which also has these same enum values.

Bullets also in Section 13.13 below table 42 for each example line.

Section 14 initiatedContent - excess blank lines.Also before heading for section 14.2

Section 14.2 separator - has tinydot bullets. Also 14.2.1, 14.2.2.3, 14.2.3.2, 16.6, 23 (8th paragraph down), 23.1, 23.5.3 in dfdl:checkConstraints function,

Section 15.1.1 indenting of numbered/lettered lists is inconsistent with rest of the document.

Section 22 - the bullets at various levels of indenting of these deep trees are not consistent. There are other problems where MS-Word won't let these trees be deep enough. Perhaps we need a different presentation style for these trees?

Section 24 Below table 70 the Notes are not a standard numbered list. Make consistent.

Section 30 - whitespace inconsistencies. E.g., "Avro," is followed by a newline before the URL eventhough it could fit fine. Some entries do that, but other entries don't do that.

Footnotes 8, 22 - have larger font than other footnotes. Also inconsistent whitespace in footnotes list after 1, 8, 22, 25, 32.
Footnote 34 the footnote number itself is larger than for th other footnotes, though the rest of the text is consistent size.

The Phrase "Remove 'when' - each of the following bullets starts with 'If'. Appears in comments list (which is after footnotes). This is a comment that can be deleted.

Some spurious change track artifacts. These add no value to be tracked, so we should just accept changes.

Immediately before Section 23.6
Immediately before Section 13.16 - there's a deleted stale 1.1 heading - just accept the delete.

Extra blank line before "Additionally" in Section 23.3.

Phrase "When a DFDL Schema is used to both parse and unparse data, then a calculated element on
parsing will normally have one or more calculated elements on unparsing."

Change "have" to "imply the use of"

Below table 77.
(page 233)
It says "Below is the same data shown horizontally with the byte numbered from right to left."

But the illustration has the bytes numbered left to righ

Section 16.6 - third list of bullets is subsumed (just narrowing of) first list of bullets. So this makes no sense. Delete 3rd list of bullets.

Throughout the document, when keywords from XSDL are used that are element names, the prefix "xs:" should be placed on them for clarity.

Where they are attribute names, they are marked by inserting "XSDL" before them as in this example:

"The XSDL minOccurs and/or XSDL maxOccurs values are used to express the valid range of occurrences."

The other keywords (names of XSDL attributes) which may need this XSDL inserted before are default, fixed, type, elementFormDefault, name, ref.

Prose that discusses the dfdl:calendarCheckPolicy (which has values strict/lax), discusses them as strict "mode" and lax "mode". We should change this to from "mode" to "policy" for consistency, given that there are properties which define modes that use suffix "Mode" on their names such as textNumberRoundingMode.

---------------------------
---------------------------
2020-04-07
---------------------------
---------------------------

Comments above this line have been applied to draft r12, or captured in comments in draft r12 as reminders.

---------------------------
---------------------------