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