Present Martin Westhead Steve Hanson Suman Kalia Geoff Judd Actions The following actions were assigned: * Scoping and context [guards and tests] (Mike) * Properties and conversions (Steve) * Revisit conversions [Steve's questions, type matching, position, speculative parsing, where are we?](Martin) * Uncertainty [wildcards, substitution groups, choices, optionality] (Geoff) * Defaults and nulls (Geoff) * DFDL Schema (Suman) Open issues: * syntax (sequences, markup) * identifying core properties and conversions (if any) * round tripping * embedded XML Day 2 Notes Properties/conversions/grouping - Steve/Suman (Suman took notes on this topic) Steve will be re-writing the current document to take on board proposals from this meeting and to start the process (with Martin) of trying to converge the properties with the conversions material. Choices and wildcards - Geoff We explored several ideas around the framework that Geoff has. Geoff will be writing these up. Comments included: * Possible use of binhex to represent "deferred" choices * Modeled uncertainty with "any" should be treated as a choice * Substitution groups should be treated as a choice * Wildcards will be handled here and "open" wildcards (unmodeled uncertainty) could be handled by dropping in a string/binhex * Schematron-like assertions could be used as choice guards such assertions could also make general statements about data validity * Use of XML Schema validation to resolve speculative parsing raises issues. (Either all DFDL parsers must validate or would get different results) Which XML Schema constructs are supported - Steve We reviewed Steves slides made various modifications key decisions: * Attributes - wait and see Final documents We had an inconclusive discussion on the structure of the final documents. Day 3 Notes Instance Validation - Efficiency of XML Schema validation - Implementation difficult of XML Schema validation - Therefore cannot force the use of full DFDL parsing - so we cannot use XML Schema validation to resolve speculative parsing - property to state validation to be used could allow parser to produce a warning error if not available - possibility: could use require just facet/value checks (not structure) - XPath evaluation required - Therefore XPath assertions for choice discrimination possible - And XPath assertions for describing valid data possible - EDI community has strong requirement for such assertions to be available (such as coexistance rules) - Is there a requirement for content validation (since construction is driven by model) - Might be useful to have standard names for classes of error DFDL Schema Validation - XML Schema valid - Syntax and semantics of annotations (annotations must be consistent with schema) - XPath references are valid (standard should describe ways validation can be done and features that can be validated, validation should not be mandated).