Hi everyone, In today's WG meeting we discussed the nested element approach VS the 'flat' element referencing approach to model associations in XML. While I don't want to introduce more complexity/options, I have worked on an unrelated schema in the past that may be worth a quick look by the WG. This schema gives you the choice of using both inline (nested) element definitions and/or element references to model relationships. Schema and sample doc at: http://tools.ngs.ac.uk/ngstools/glue2proposal/nestingAndElementReferencesSam... Brief description: The data copy schema defines the <DataCopy> document root that defines a single <common> element and one or more <copy> operations. Each <copy> either references or nests an implementation of an abstract data source and an abstract data sink. Importantly, the schema allows both inline (nested) element hierarchies and/or element references to model relationships. Having the option of both these approaches reduces element repetition since multiple <copy> operations can reference the same shared data source or sink. For increased document clarity, shared elements MAY be nested as children of the global <common> element. E.g. a single dataSource can be defined as a child of <common> and be subsequently referenced by multiple <copy> operations. This approach may be useful for the GLUE rendering: A single entity is never repeated. Rather, shared entities are referenced. This is similar to the teragrid <Entities> element (with "glue:ID_t" references). In addition, I think we may? need to introduce a new element bag akin to the teragrid <Entities> element so that all entities can be defined in a single document (as per Warren's use-case). For example, consider defining both a <UserDomain> and an unrelated <Service> in the same doc; currently this would not be possible without an abstract parent container element such as 'Entities[1]'. ([1]Note, the abstract element and substitution group proposal still holds, e.g. all the concrete elements listed as children of the 'Entities_t' could/should be replaced with corresponding abstract definitions which would facilitate future extension/profiling of that schema). Cheers David ========================== David Meredith Scientific Computing Technology eScience Daresbury Laboratory Tel: +44 (0) 1925 603762 Fax: +44 (0) 1925 603100 (Site) Email: david.meredith@stfc.ac.uk Skype name: davidismeredith -- Scanned by iCritical.