1. OGF22 - No update from Mike.
2. Specification Drafts - Steve and Alan have distributed a version of Mike's plan for the next few versions. of the specification with work items assigned to individuals. Simon asked for clarification regarding his item "2-level description (schema components)" - this covers reviewing and updating the DFDL schema abstract data model document (distributed by Steve, with the agenda for this meeting) for inclusion in the DFDL specification, to replace and extend the existing UML diagram.
3. Expression Language - Alan will update and distribute a new draft of the expression language proposal.
4. Property Precedence - Steve has prepared a proposal as a Freemind mind map and would appreciate any review comments, especially with regard to the questions distributed along with the proposal. The group briefly discussed some of these, and Steve will email Mike asking for his opinion on some of these issues.

• Regarding dfdl:escapeScheme, and how it applies when lengthKind=end of data - the specification plan includes a review of the escapeScheme mechanism and this issue can be discussed then.
• While discussing the enum used for dfdl:nullKind, Simon observed that this issue has not arisen in PolarLake's parser as it does not have a well-developed concept of null.
• Steve felt we should perhaps remove the Advanced Text Delimiter Supplement.
• Entity References - Alan and Ian have been looking at this, and will prepare and distribute a revised proposal. Steve will write a proposal to cover whitespacing.

• All associations originating from DFDLSchema should have black diamond instead of empty diamond because DFDL schema object would be the owner of these objects. Cardinality of relationship is not explicitly shown; I think the default cardinality as per standard is 1 which won't be correct in this case. e.g. DFDLSchema would have more than 1 global elements/ types etc..  Likewise there would be black diamond relationship from Element Declaration/Simple Type Definition/ComplexType Definition to DFDL Annotation Base. (Suman)
• In the open source XML Schema model, there is no explicitly defined object for element reference and group reference. Same  XSDElementDeclaration or XSDGroupDefintion are used to model references. It is determined programmatically and I think it would be better to use the open source XML schema model as source model and show relationship of DFDL Annotations attached to the XSD schema model. (Suman)

• Need cardinality adding (Steve)
•  White v black diamond not correct (Suman)
• What does 'ref' mean on the link from Particle to Element Declaration ? (Steve)
• Link  from Complex Type Definition to Particle - this can only be to a Model Group subclass (Steve)
• May want to add the following pointer to make it complete: complex type definition -> (base type) -> complex type definition (Sandy)
• I know this is probably not needed by DFDL; but may help to include it for completeness. We have it for simple types; may confuse people if it's not on compelx types. (Sandy)

• Wondering whether this is necessary. It's a middle step, possibly only useful to implementors (Sandy)
• 1st bullet - talks about a limitation in the XSDL model - I'd like Sandy to take us through this. MRM carries annotations on groups and group refs.(Steve)
• 1st bullet - the practical limitation appears to be that you can't override the properties of a global group on a group reference, like you can with elements. Is this going to be an issue? (Steve)
• 4th bullet - prohibiting dfdl:discriminator on xs:choice seems sensible (Steve)
• Should "variable definition" be derived from "DFDL annotation base"?  (Sandy)
• The current diagram suggests that "variable definition" can both be part of a format base or as a standalone annotation (outside of a format). Is this true? (Sandy)
• Can "hidden" be viewed as a specialized element reference? (Sandy)
• This only implies a "base class" pointer from "hidden" to "element reference". There really isn't much benifit in doing this. It just *feels* better. Don't feel strongly. (Sandy)

• Haven't finished reviewing it carefully. (Sandy)
• Inheritance is used much more often in this diagram. e.g. "Any Element Wildcard" is derived from both "Occurrence Properties" and "DFDL properties Base". Is this intentional? Feels counter-intuitive to me. Components should *have* properties, rather than *be* properties. (Sandy)
• Wondering whether it makes sense to combine diagrams 2 and 3. That is, a single diagram that has everything inherited/flattered, but don't attempt to remove properties that are not used at runtime. e.g. keep DFDL Schema etc. (Sandy)

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU