[glue-wg] XML rendering style

Fri Jun 15 09:29:50 EDT 2012

On 06/14/2012 05:15 PM, david.meredith at stfc.ac.uk wrote:
> 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).

If this errata makes sense

https://forge.ogf.org/sf/wiki/do/viewPage/projects.glue-wg/wiki/GLUE20Errata

"In the GLUE Specification v. 2.0, page 11, the relationship 
AdminDomain-Service in AdminDomain has not a counterpart in Service 
(page 13). Service object should have a relation to AdminDomain with 
multiplicity 1."

Then is not possible for a Service to belong to multiple AdminDomains.

I asked this question myself and I believe it would make sense to have 
multiplicity >= 0, but then it should be clear that there is no 
correspondence between the old glue1 concept of "site" and the GLUE2 
concept of domain.

Furthermore the UML model seems to say that the association between 
Service and AdminDomain is an aggregation without multiplicity on the 
endings, but * multiplicity on the association. So in principle a 
Service can "live" without a Domain and can even have more than one.

Anybody remembers why such a strong multiplicity in the errata? I 
believe this is only due to the old glue1 site concept. Or it's just 
that the errata is not valid?

Cheers,
Florido

>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

-- 
Florido Paganelli
Lund University - Particle Physics
ARC Middleware
EMI Project