[glue-wg] XML rendering comments

[Warren Smith]

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