[dfdl-wg] notes from F2F 2006-03-01

[Mike Beckerle]

Attendees:

Bob McGrath - NCSA
Martin Westhead - Avaya
Suman Kalia - IBM
Geoff Judd - IBM
Steve Hanson - IBM
Mike Beckerle - IBM

Agenda Review

Context doc discussion - Martin

Issues list:
- write once context variables - expressiveness limit?
- list valued context variables - define them then 'commit' to make them 
read-only?
- default values for context variables? - breaks write-once behavior?

- hidden: don't want paths to hidden peers to be any different from paths 
to non-hidden peers - mikeb
- hidden: need to specify the order of traversal for parsing
- hidden: on output, traversal order is very different
- need inputCalc and outputCalc

- hidden: currently says hidden can only appear where elements could 
appear
- exception needed - simple types need hidden complex sub-structure - 
'repDef'
- maybe use hidden attributes and avoid element substructure for simple 
types.
- or have an explicit repDef construct with a full indirection from a 
simple type to a complexType that is its representation

- Roundtrip problem is not general data transformation
- Separate tracker for round-trip to data issue
- Copyright slugline example is sufficient 


Bundles:

- is this just really for the top-level statements like conversion 
declarations?
- revisit this once we've overviewed the scoping stuff - probably some 
features of one or the other are redundant.
- bundles are like xs:include except can be used not-only at top-level.

Conversions:

- are an expository tool
- organize properties into libraries
- plug in conversions are allowed, but built-in property/conversions don't 
have to be implemented using the plug-in mechanism
- ? DFDL systems might be allowed to not even implement plug-ins

- need to explain XML all the way down idea more clearly. Stream of 
xs:byte, then streams of higher types.

- test guard should select the conversion
- once selected then requirements 

- if you can't find any conversion for something then the schema is 
invalid.
- if the guard of a conversion is satisfied, but required properties are 
not present in the context, then the schema is invalid.

- issue: can more than one conversion have the same name?
- issue: what are the update rules for the conversion list in the context 
as you extend the context with new conversions

- issue: type matching - match exactly? or ignore restrictions? E.g., 
string of length 1 matches general string, but general string doesn't 
match string of length 1.

- issue: type A has child derived type B. Conversions for type B cannot be 
selected based on existance of conversions that have source/target type A. 
(isA relationship not involved in conversion selection). The type matching 
has only to do with restrictions actually. 

- issue: can different dfdl implementations use different search 
algorithms? Probably not. They must choose the same set of conversions so 
the standard can specify the selection algorithm exactly. Implementations 
are free to use different more efficient algorithms so long as they choose 
equivalent conversion chains. (need notion of equivalent conversion 
defined)

- issue: context needs to contain the input-stream type (in the "C" 
context, or just in the informal context of the parser? E.g., you can ask 
what is the type of this element without that having to be in the "C" 
context. The type of the source stream could also be in this informal 
context.

- property names should be namespace qualified when used in guard and 
required formulas of conversions.

- conversions stuff doesn't cover all properties. E.g., choice 
discriminators aren't described how they use as part of conversions.

- issue: alignment - can there be an alignment conversion

Extensibility:

- defineConversion - should express required properties test as well as 
input type and output type.

- whitebox conversions - doubleInt example doesn't seem intuitive to some. 

   suggestion is to name the complex type, separate the named conversion 
definition and just reference the type name


- change keyword for guards to 'guard' not test, since test is used for 
statement conditional execution.

- name conflicts: guard vs. selector vs. test - define terms specifically.

- need tracker item re: output

- steve hanson suggests using EDI security segments for the useStream 
example.

- guard optional - if not specified means guard="true"

Scoping:

- simplify: don't allow base format on construct-specific annoation 
elements if inside dfdl:default or dfdl:defineFormat.

variable defaults in the context:

- if a variable has a default value, and you keep track of whether anyone 
has received the default value if they have received the default value 
then an attempt to set it is an error. This is consistent with single 
assignment behavior. 

variable declaration scope

- a dfdl:declare on an xsd:element with maxOccurs > 1 is about the type, 
not the particle (not about the entire repeating element vector, but about 
each element within).

external control of format:

- should do overrides much like element references, i.e., external 
controls have override behavior.

leaf contexts:

- ? do these distinguish properties from variables 

Mike Beckerle
STSM, Architect, Scalable Computing
IBM Software Group
Information Integration Solutions
Westborough, MA 01581
voice and FAX 508-599-7148
home/mobile office 508-915-4795

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20060301/4c350c8e/attachment.html