[glue-wg] XML rendering style

Thu Jun 14 13:01:39 EDT 2012

Warren, Steve, David and all OGF GLUE members,

Concerning the hierarchical versus flat renderings, I consider that :

-  The GLUE 2 schema itself does NOT define any hierarchy.
    So, different stakeholders necessarily have different preferences 
for the hierarchy (for example, is the placement of 'Activity' at the 
top of the hierarchy any more stupid than any other class ?).
    Therefore, I doubt on the possibility of a worldwide agreement on 
any hierarchical rendering.
    Besides, any hierarchical rendering will stuck when entities whose 
class was previously supposed to be only 'child' will come up with 
relationships with more than 1 entity whose class was previously 
supposed to be only 'father'.

-  The distributed infrastructure covered by the GLUE 2 schema is NOT 
managed along a strict hierarchy, but the publication of entity 
attributes towards the Information System tends to be performed locally 
by the entity itself, WITHOUT any knowledge of the entity which is 
considered 'father' by some hierarchical rendering.

-  For security, Information Systems must be able to publish subsets of 
the entities and attributes depending NOT on any predefined hierarchy, 
but depending dynamically on the requester credentials,

-  User queries on the Information Systems do NOT follow a strict 
hierarchy, but tend to be ANY retrieval of attributes of entities of a 
first class linked in ANY relevant way to entities of a second class 
having given values for some attributes (think of SQL queries using ANY 
(number of) legal table joins).
    Therefore, hierarchical renderings need to provide references to ALL 
related entities whose class is NOT a direct parent or child.
    This ends up with almost as many references than in a flat model, 
and requires the SAME BURDEN of validation of reference consistency than 
any flat model.

In conclusion, like Warren, Steve and David, I vote for flat renderings, 
as well using XML as JSON.

Like David, I'll not be able to attend the meeting in Delft in person, 
but I will aim to skype in.

Best regards.

-----------------------------------------------------
Etienne URBAH         LAL, Univ Paris-Sud, IN2P3/CNRS
                       Bat 200   91898 ORSAY    France
Tel: +33 1 64 46 84 87      Skype: etienne.urbah
Mob: +33 6 22 30 53 27      mailto:urbah at lal.in2p3.fr
-----------------------------------------------------

On Thu, 14/06/2012 17:15, 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). 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3895 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://www.ogf.org/pipermail/glue-wg/attachments/20120614/7032def2/attachment.bin>