This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf6430?nav=1&selectedTab=comments at Sun, 06 Nov 2022 13:33:25 GMT SourceForge : artf6430: 037 - glossary/definitions/terminology - general and specific

Project Home

Tracker

Documents

Tasks

Source Code

Discussions

File Releases

Wiki

Project Admin
Search Tracker
Project: DFDL-WG     Trackers > Specification version 1.0 > View Artifact
Artifact artf6430 : 037 - glossary/definitions/terminology - general and specific
Tracker: Specification version 1.0
Title: 037 - glossary/definitions/terminology - general and specific
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?
Submitted By: Michael J Beckerle
Submitted On: 01/06/2010 4:30 PM EST
Last Modified: 11/02/2010 5:58 AM EDT
Closed: 11/02/2010 5:58 AM EDT

Status / Comments Change Log Associations Attachments  
Status  
Group: *
Status:* Closed
Category: *
Customer: *
Priority: * 2
Assigned To: * None
Reported in Release: *
Fixed in Release: *
Estimated Hours: * 0
Actual Hours: * 0
Comments
Steve Hanson: 11/02/2010 5:58 AM EDT
  Action: Update
Closed set to 11/02/2010
Status changed from Open to Closed
Michael J Beckerle: 01/06/2010 4:40 PM EST
  Comment:
Add this too - Standardize terminology: choices have 'branches' not 'alternatives', not 'arms' and especially not "choices" or "sub choices" which is 
very confusing.
  Action: Update
Michael J Beckerle: 01/06/2010 4:30 PM EST
  Action: Create


 
 
 
< Previous
 
 
Next >
 


The Open Grid Forum Contact Webmaster | Report a problem | GridForge Help
This is a static archive of the previous Open Grid Forum GridForge content management system saved from host forge.ogf.org file /sf/sfmain/do/go/artf6430?nav=1&selectedTab=comments at Sun, 06 Nov 2022 13:33:25 GMT