[glue-wg] XML rendering style

david.meredith at stfc.ac.uk david.meredith at stfc.ac.uk
Thu Jun 14 11:15:34 EDT 2012


Hi Warren, 
> I've seen a couple of comments that make me wonder if I'm not alone in this.

Yes, after being introduced to your schema in the last WG meeting I think the flattened style may be preferable, especially for rendering GLUE entities that can exist standalone and have their own lifetime that is not tied to an associated/parent entity, i.e. a weak dependency as defined by UML Aggregation/Association (note, a fully exploded/fully flattened structure may not always be appropriate for rendering those elements whose lifetime is strictly tied to their associated element/parent, i.e UML Composition).  

Another example that I think illustrates your point (below) is that a single Service could potentially be a member of two AdminDomainS (perhaps not common but it's possible). For example in GOCDB, a single Service instance may be hosted by a both a physical site (which correlates to an AdminDomain) and a virtual site (which would also correlate to an AdminDomain). Given the nested approach, one AdminDomain would need to nest this service and the other AdminDomain would either need to back-reference the nested service or define a duplicate. 

Couple of possible suggestions/thoughts for the meeting: 
1) I think the core entities should be importable for use in other 3rd party schema files. This would require them being made global. I realise that this would create more global elements other than the Entities element, but this is normal in my experience in XSD. It can be clearly documented that the 'Entities' element is the intended document root. 
2) I also think that abstract/substitution group concept may also be applicable so that profiles can define sub-type specialisations in future (e.g. new services types) and subsequently nest those specialisations within 'Entities' without having to modify the original XSD Entities element. 

Unfortunately I'll not be able to attend the meeting in Delft in person, but I will aim to skype in. 
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 11:57
> To: glue-wg at ogf.org
> Subject: [glue-wg] XML rendering style
> 
> 
> I've been meaning to follow up our last conference call with an email about
> the "style" of the XML rendering. You all probably know that I prefer the flat
> style over the hierarchical. The current hybrid schema is a compromise between
> these two approaches (I think it's great that people are willing to
> compromise, btw), but what I mentioned on the call is that I think I prefer
> the flat (https://github.com/OGF-
> GLUE/XSD/blob/master/schema/teragrid_glue_2.0_r01.xsd) or hierarchical
> (https://forge.ogf.org/sf/docman/do/downloadDocument/projects.glue-
> wg/docman.root.drafts/doc15515) styles to the hybrid (https://github.com/OGF-
> GLUE/XSD/blob/master/schema/GLUE2.xsd) one. I've seen a couple of comments
> that make me wonder if I'm not alone in this.
> 
> One of the high-level concern that I have with the hybrid approach is that a
> GLUE2 entity can appear in several different places in a GLUE2 document (this
> is why it is a hybrid approach, of course). For example, a document could only
> have a ComputingActivity, it could be ComputingActivities ->
> ComputingActivity, or ComputingEndpoint -> ComputingActivities ->
> ComputingActivity. As was mentioned on the call, you can search the document
> for that element name, but that seems a bit inelegant to me and implies that
> the hierarchical structure of the document doesn't even matter.
> 
> Another high-level concern is linking of entities. The hierarchical approach
> linked many entities via parent-child in the XML hierarchy. A flat approach
> links them using IDs to refer to each other. With a hybrid approach something
> like both of these need to be supported and this seems a bit confusing - the
> ID references will be in the schema, but only needed if a particular XML
> document doesn't use a hierarchy. This could lead to confusion when
> creating/parsing documents.
> 
> I have some other comments about the current hybrid schema, but I'll send
> separate emails about those.
> 
> 
> Do we need a discussion about these three different styles? There seems to be
> an assumption that there is agreement on the compromise hybrid style, but I'm
> not sure that is the case...
> 
> 
> Warren
> 
> 
> -----Original Message-----
> From: glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On Behalf Of
> david.meredith at stfc.ac.uk
> Sent: Wednesday, June 13, 2012 11:14 AM
> To: navarro at mcs.anl.gov; glue-wg at ogf.org
> Subject: Re: [glue-wg] OGF 35 meeting and preparation reminder
> 
> Hi everyone,
> Regarding the XML rendering:  for me the most important agenda item is to make
> a decision between the flattened document style (e.g. like the Teragrid
> rendering), or a nested/hierarchical approach (the current style described in
> the word doc), or somewhere between.  Both styles render associations using
> their own 'identifier' elements that reference the IDs of associated elements.
> 
> Until last phone meeting, I had not seen the Teragrid rendering which looks
> good to me. This approach may be preferable compared to defining deeply nested
> element trees. Therefore, I think the agenda item iii) needs to come first
> before the substitution group stuff.
> 
> Regardless of the preferred style, I still think we need to cater for sub-
> typing of the core entities by future profiles at the outset.  I am pretty
> sure the abstract-element/substitution group approach may also be useful to
> the flattened style. For example, maybe the global 'Entities' element could
> define abstract elements such as 'AbstractService' so that concrete
> specialisations can be substituted in place (e.g. Service, ComputingService,
> StorageService and potentially any future profiled service that can substitute
> for AbstractService).  Same sort of thing could apply to abstract Domain and
> AdminDomain/UserDomain etc.
> 
> Cheers
> David
> 
> > -----Original Message-----
> > From: glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On
> > Behalf Of JP Navarro
> > Sent: 13 June 2012 11:02
> > To: OGF GLUE WG
> > Subject: [glue-wg] OGF 35 meeting and preparation reminder
> >
> > Dear GLUE WG,
> >
> > Just a reminder of our OGF 35 GLUE2 working group meeting this coming
> > Sunday June 17th 13:30-15:00 Central European Time.
> >
> > http://ogf.org/gf/event_schedule/index.php?id=2530
> >
> > Our agenda:
> >
> > i) Substitution group discussion and agreement
> > ii) EGI service names and types discussion
> > iii) Globalized schema and cross-references
> > iv) Future directions discussion: JSON rendering, etc.
> >
> > Recent action items to prepare for this meeting:
> >
> > Action Item: Provide a slide for OGF on how to implement the Glue
> > Entities Bag high-level element, probably with example: Assigned to:
> > David Action Item: A slide will be presented in next OGF to explain
> > the problem in greater detail. Assigned to: Warren, JP
> >
> > We will post meeting call-in information when it's available.
> >
> > Regards,
> >
> > JP
> > _______________________________________________
> > glue-wg mailing list
> > glue-wg at ogf.org
> > https://www.ogf.org/mailman/listinfo/glue-wg
> --
> Scanned by iCritical.
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg
> _______________________________________________
> glue-wg mailing list
> glue-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/glue-wg
-- 
Scanned by iCritical.


More information about the glue-wg mailing list