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-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On
Behalf Of Warren Smith said: ComputingActivity_t has a reference to a ComputingShare using a LocalID_t (I'm not sure how a LocalID differs from an ID, actually).
That sounds like a mistake somewhere, ComputingShare should have an ID like anything else. The only things with local IDs are Extensions. (A local ID only has to be unique relative to its parent object, IDs have to be globally unique.) Stephen -- Scanned by iCritical.
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@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of Warren Smith Sent: 14 June 2012 16:32 To: glue-wg@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@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg -- Scanned by iCritical.
participants (3)
-
david.meredith＠stfc.ac.uk -
stephen.burke＠stfc.ac.uk -
Warren Smith