[glue-wg] flat xml rendering

Thu Oct 4 07:06:31 EDT 2012

Hi all,

Sorry for this late answers of mine, I had the time to follow the XML
subject just now.

On 09/07/2012 12:50 AM, Warren Smith wrote:
>
> Ok, I see what you are saying - I'm just now looking at the schema
> and I had some assumptions about it that weren't correct. However,
> after a little reading about XPath, it looks like there are a few
> ways that you can return all activities without requiring an
> Activities element as a parent.
>
> /Entities/*[contains(local-name(),'Activity')] - returns all elements
> under Entities that have 'Activity' in them
>
> /Entities/*[substring(name(), string-length(name()) - 7) =
> 'Activity'] - returns all elements under Entities that end in
> 'Activity'
>
> These XPath expressions aren't as nice as '/Entities/Activities/*',
> but they aren't that bad and I don't know how often this case will
> come up. In XPath 2.0, it looks like there is an 'ends-with()'
> function that allows a much simpler version of the 2nd expression
> above. I personally wouldn't use the additional complexity of these
> XPath statements as a reason to add *s parent elements.
>

I think the queries you suggest are definitely less handy that having 
groupings.

>
> Sorry that I had to miss the last telecon since I was on vacation, so
> I apologize if some of my comments about the schema were discussed:
>
> * My preference is to do away with all ...s grouping elements. I
> still don't see them as being needed (or desired).
>
> * If the decision is to keep the ...s grouping elements (I hope not!
> :-P ), the schema should probably use them consistently (e.g.
> wherever the element has maxOccurs="unbounded"). They aren't being
> used right now in quite a few spots: Location, Contact, the elements
> at the end of ExtensibleEntities_t, and number of other complexType
> definitions.
>

You probably mean they have not been used by your software so far, I 
guess...

We use them a lot in NorduGrid ARC GLUE2 XML rendering and we would like 
to use them in the coming EMI Execution Service information model, this 
is why I was asking David to integrate them.

> * Why is there a BaseType="..." attribute on many of the elements? It
> seems like redundant information and looking at the schema, I can't
> figure out why they are needed...
>
> * The Extension representation is slightly different from how I
> defined them in the TeraGrid schema. This schema has elements for
> LocalID and Key (as well as Value). For the TeraGrid schema, I had an
> Extension element with Key as an attribute (I forgot to include a
> LocalID attribute), and the text of the Extension element was the
> value. This schema mostly avoids attributes, so using elements
> probably makes more sense...
>
>
> That's all I notice at this point.
>
>
> Warren
>
>
> -----Original Message----- From: david.meredith at stfc.ac.uk
> [mailto:david.meredith at stfc.ac.uk] Sent: Friday, August 31, 2012
> 10:00 AM To: Warren Smith; stephen.burke at stfc.ac.uk;
> florido.paganelli at hep.lu.se; glue-wg at ogf.org Subject: RE: [glue-wg]
> flat xml rendering
>
> Hi Warren, In the glue2_2.xsd at
> http://redmine.ogf.org/dmsf/glue-wg?folder_id=32, there is no
> '<ComputingActivites>,' only '<Activities>' which serves to group the
> elements that are substitutable for the 'AbstractActivity'
> substitutionGroup (so currently this includes both 'Activity' and
> 'ComputingActivity' - and of course any activities that may be
> profiled in the future that may also define the same
> substitutionGroup). The relevant XSD fragment is as follows (line
> 139) - note that it simply serves as a wrapper around
> AbstractActivity:
>
> <element name="Activities" minOccurs="0" maxOccurs="1">
> <complexType> <sequence> <element ref="glue:AbstractActivity"
> minOccurs="0" maxOccurs="unbounded"/> </sequence> </complexType>
> </element>
>
> Therefore, given the following instance doc:
>
> <Entities... > ... <glue:Activities> <glue:Activity
> BaseType="Activity"> <glue:ID>http://activity1.ac.uk/1</glue:ID>
> <glue:Associations/> </glue:Activity>
>
> <glue:ComputingActivity BaseType="Activity">
> <glue:ID>computingActivity1</glue:ID> <glue:State>some
> state</glue:State> <glue:Owner>someone</glue:Owner>
> <glue:Associations/> </glue:ComputingActivity>
>
> ...here nest more elements that can substitute for the
> AbstractActivity substitutionGroup... </glue:Activities> ...
> </Entities>
>
> To select all of the different flavours of Activity in a single
> query, you could use the following XPath: '/Entities/Activities/*'.
> Similarly, for all services; '/Entities/Services/*' and for all
> Endpoints; '/Entities/Endpoints/*' etc.  I guess it depends if you
> think this is useful. Without the 'Activities' element, to select all
> the different types of activity, you would currently need to issue
> two XPath queries and concat the two docs: '/Entities/Activity' and
> '/Entities/ComputingActivity'.
>
> Personally, I think it is useful to be able to select/collapse all of
> the Services, Endpoints, Activities etc with one button click or
> query, especially when considering large documents that may have
> 1000s of endpoints listed. Either way, it's only a small change from
> the version that does not define these grouping elements
> (http://redmine.ogf.org/dmsf/glue-wg?folder_id=31)
>
> David
>
>> -----Original Message----- From: Warren Smith
>> [mailto:wsmith at tacc.utexas.edu] Sent: 31 August 2012 14:48 To:
>> Burke, Stephen (STFC,RAL,PPD); Meredith, David (STFC,DL,SC);
>> Meredith, David (STFC,DL,SC); florido.paganelli at hep.lu.se;
>> glue-wg at ogf.org Subject: RE: [glue-wg] flat xml rendering
>>
>>
>> My general opinion is not to have any -ies elements (e.g.
>> ComputingActivities) to group elements. To me, this grouping of
>> elements (e.g. ComputingActivity) isn't needed in XML. It doesn't
>> seem to make it any easier to process the XML using SAX or DOM. It
>> seems easy to find all -y elements in a document without a -ies
>> element as a parent for visualizing. Similarly, it also seems easy
>> to find -y elements in an XML document if you want to translate it
>> to LDAP or SQL or whatever.
>>
>> I haven't really done much xPath... Can someone explain how
>> grouping elements would help? It seems like either way you'd
>> include 'ComputingActivity' in the expression. That is the
>> expression would start with
>> "/Entities/ComputingActivities/ComputingActivity..." or
>> "/Entities/ComputingActivity...".
>>
>>
>> Warren
>>
>>
>> -----Original Message----- From: glue-wg-bounces at ogf.org
>> [mailto:glue-wg-bounces at ogf.org] On Behalf Of
>> stephen.burke at stfc.ac.uk Sent: Friday, August 31, 2012 5:20 AM To:
>> david.meredith at stfc.ac.uk; david.meredith at stfc.ac.uk;
>> florido.paganelli at hep.lu.se; glue-wg at ogf.org Subject: Re: [glue-wg]
>> flat xml rendering
>>
>> glue-wg-bounces at ogf.org [mailto:glue-wg-bounces at ogf.org] On
>>> Behalf Of david.meredith at stfc.ac.uk said: I think these group
>>> elements could be useful for simplifying XPath queries and for
>>> visualizing large documents with tools that can collapse/expand
>>> elements (see attached image, also uploaded at the following
>>> link).
>>
>> Bear in mind that in the production Grid there are about 4000
>> endpoints, so grouping may not help a lot with visualisation unless
>> you do it more finely.
>>
>> Stephen
>>
>> _______________________________________________ glue-wg mailing
>> list glue-wg at ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
> -- Scanned by iCritical.
>

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