Not seen an agenda, I think the following are up for discussion: - Go through last week's minutes - Discuss Geoff & Steves' property precedence - Discuss Mike's UML for DFDL schema subset IBM comments: UML for DFDL subset of XSDL - 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) UML for DFDL annotations on XSDL - 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) UML for post-scope resolution and inheritance flattening - 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) Regards, Steve Steve Hanson WebSphere Message Brokers Hursley, UK Internet: smh@uk.ibm.com Phone (+44)/(0) 1962-815848 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