[glue-wg] XML rendering comments

[david.meredith at stfc.ac.uk]

Hi everyone, 
To show that the abstract element/substitution group concept is equally applicable to the flattened XSD style, I have produced a modified version of the Teragrid schema with an accompanying XML doc example at the link below. Please note, I have not addressed some of the other (minor) issues reported by Warren; this example serves to demonstrate abstract elements with substitution groups in the flat XSD style. 

The main modifications include: 	
1) Core elements are made global so that 3rd party XSD can import this schema and re-use those elements. 
2) The modified XSD includes abstract elements with corresponding concrete implementations (e.g. abstract <Domain> and concrete <AdminDomain> and <UserDomain>). 
3) The <Entities> element references abstract elements. In doing this, new element specialisations that define the appropriate substitution group can be nested within the 'Entities' element in any future/extending profile (requires no future modification of the glue XSD).

http://tools.ngs.ac.uk/ngstools/glue2proposal/modifiedTeraGridXSD_Sample.zip  

Cheers, 
David

> -----Original Message-----
> From: glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On Behalf Of
> Warren Smith
> Sent: 14 June 2012 16:32
> To: glue-wg at ogf.org
> Subject: [glue-wg] XML rendering comments
> 
> 
> Hi all,
> 
> Below are some comments about the current hybrid XML rendering (we talked
> about a lot of them on the last call):
> 
> * Not all elements can currently be at the top level. Examples are
> ComputingShare, ComputingEndpoint, and several storage ones. I think major
> elements like these should also be allowed at the top level for consistency as
> well as not needing placeholder parent elements to have a valid glue2 document
> with this information.
> 
> * I think that allowing a generic top-level element ("glue" or whatever) would
> be good. It would make it possible to have documents with several somewhat
> unrelated entities without forcing a lot of dummy hierarchical structure. For
> example, a document that has ComputingActivities and ExecutionEnvironments. I
> don't know of anyone that needs this example specifically, but I can imagine
> someone wanting to publish documents that contain the more dynamic information
> like this.
> 
> * A different question is whether there should only be a generic top-level
> element (in contrast to the current approach that allows many of the entities
> to be the top-level element). I think I prefer to have a single top-level
> element and allow any of the entities to be under that element (with
> minOccurs="0"), just so that we have a little more predictable document
> structure. Based on the call, I don't think we'd have a consensus about this.
> 
> * Something to think about is how to represent associations that aren't
> represented hierarchically (or aren't always represented hierarchically). An
> example is ComputingActivity and ComputingShare. In the current schema,
> ComputingShare_t has a associations to ComputingActivities using ID_t.
> ComputingActivity_t has a reference to a ComputingShare using a LocalID_t (I'm
> not sure how a LocalID differs from an ID, actually). I think that it may be
> better if the many refer to the one than having the one refer to the many or
> to refer both ways. By this I mean that ComputingActivity_t should include the
> LocalID_t of its ComputingShare, but ComputingShare_t should not include the
> ID_t of its ComputingActivities. I prefer this approach because in general I
> think that the "many"s may be updated more often than the "one"s (e.g.
> ComputingActivities may be updated more frequently than ComputingShares) and
> if the "one"s refer to the "many"s, they are forced to be updated.
> 
> * Related to the above, I saw that ComputingActivity_t doesn't have a
> ComputingEndpointID element. Perhaps it should, depending on which direction
> we're representing associations.
> 
> * A minor question is why have XXXies in the complex types? For example,
> ComputingActivities in ComputingEndpoint_t? An alternative is to just have
> ComputingActivity with maxOccurs="unbounded".
> 
> 
> Thanks and sorry for having so many points in one email,
> 
> 
> Warren
> 
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg
-- 
Scanned by iCritical.