[DFDL-WG] Agenda for call today
Steve Hanson
smh at uk.ibm.com
Wed Jan 16 11:01:29 CST 2008
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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/dfdl-wg/attachments/20080116/9f71c06e/attachment-0001.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: DFDL schema abstract data model.doc
Type: application/octet-stream
Size: 1154048 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/dfdl-wg/attachments/20080116/9f71c06e/attachment-0001.obj
More information about the dfdl-wg
mailing list