Description: |
This is an issue about how the spec should be organized, along with specific things needing definition.
Right now we have some terminology introduced in an up-front glossary section.
Other terms are introduced with blocks of "definition: xyz" type paragraphs - layed out in various ways that are
inconsistent.
We have lots of inter-section cross references (most of which are TBD), so as to refer to the place where something is
discussed further, where the definition of something is, etc.
The problem with moving all the definitions up to the glossary section is that then they are located away from the
material which motivates their definition. You end up with a huge glossary which is very unmotivated.
On the other hand, using definitions at the point of first introduction is also a problem - because given the way the
spec is organized, often a term is used before the section where it is more clearly explained.
Here is a list of terms we use formally in many places. These need to have crisp definitions in the glossary or
elsewhere.
• Augmented infoset
• Potentially represented item
• Data stream
• Dynamic scope (of a variable memory)
• Dynamic extent (of a complex type element in the data stream)
• Lexical scope
• Explicit - as in "explicit" properties versus "default" properties (section 10.4)
• Default properties
• Known length - "has known length" - for dfdl:lengthKind
o and "when the parent length is known" (14.3.2)
• Encoding, code-page (also - should choose 'encoding' or 'character-set encoding' as the term that is preferred over
code-page throughout)
• Scanned (14.3.2) and scanning and scanability (16.2) (also 15.1.1 - dfdl:escapeScheme section should mention scanning
and probably should be the place that explains it in detail)
o Also 16.3.2 mentions "delimiter scanning" (as opposed to "regular expression scanning" which is somewhat different.)
• Can we change "physical length" to "representation length" throughout?
o We already have a formal definition of representation length, and unpadded length. Should these move to the glossary
section?
• Variable width (of a character set encoding)
• Schema-definition-order (dfdl:sequenceKind)
• 16.5 Floating Elements - "contains non-element content" Use of the word "content" here is problematic - we use
content and framing, and that's entirely different usage than this.
• Content
• Framing
• 23.1.1 "used as parameters"
• global context - we don't use this notion in explaining DFDL semantics anymore. Either we start using it, and put
appropriate definitions in, or omit the 2 or 3 places in the text using it.
Other terminology issues:
• too many cross references. Suggest we leave out cross references unless we really think we've forgotten the section
or that someone won't be able to find it easily.
• 15.13 - should we use this formatting for definitions everywhere? There are several different ways that this sort of
definition sections are layed out. Also should these go in the glossary/terminology section?
|