Thanks david, this was very enlightening, I hope it will help the working group to process your request. Cheers, Florido On 04/16/2012 02:49 PM, david.meredith@stfc.ac.uk wrote:
Hi Florido, Comments interleaved below. There seems to be some confusion with regard to what is being proposed - only the modified glue2.xsd forms the proposal (i.e. the newly proposed AbstractService and AbstractEndpoint elements). The glue2gocdbExtensions.xsd schema is merely an example showing how you can subsequently extend these abstract elements with the use of xsd:substitution groups if needed for future profiling of new Service and Endpoint types. Importantly, the modified glue2.xsd still defines its own (concrete) set of standard glue2 Service and Endpoint elements that form the core/standard set. Further details explained below.
Cheers, David
Looking at your proposal, it seems to me that the only thing you need is to have - two more attributes in the Service Monitored, Beta -two more attributes in the Endpoint object, namely: DowntimeSeverity DowntimeClassification I second Stephen idea of having something generic like MonitoringService and MonitoringEndpoint
The glue2gocdbExtensions.xsd is not part of the proposal, only the modified glue2.xsd.
I also think that this should be propagated in the specification at some point... What I didn't get is, is there an issue with extending these objects with the existing xsd schema? I think you mentioned something in Munich... What is this AbstractService and AbstractEndpoint exactly for? Creating new object names?
In the GLUE2 specification doc it states "For Grid services requiring a richer set of attributes for the Endpoint, specific models MAY be derived by specializing from the Endpoint class and adding new properties or relationships".
However, in current (unmodified) glue.xsd, the Service_t defines an 'Endpoint' element that can't be extended with a custom Endpoint specialisation because Endpoint must be of type 'glue:Endoint_t' (<element name="Endpoint" type="glue:Endpoint_t" minOccurs="0" maxOccurs="unbounded"/> ). The problem is that 'Endpoint_t' is not abstract and so can't be substituted with an Endpoint specialisation using an xsd:substitution group. The same problem occurs for the Service. Therefore, I am proposing that the Endpoint and Service elements be defined as abstract. The standard glue2 services (Service, ComputingService and StorageService) then provide a core set of concrete elements (as they are defined within the glue2.xsd).
What I am afraid of is the crazy creation of thousands of custom endpoints that in my opinion will totally make useless the main purpose of GLUE2, which is, always in my opinion, to avoid having product-specific renderings...
Nope, this is not an issue because the modified glue2.xsd defines its own standard set of glue2 Service and Endpoint implementations. These are defined within the glue2.xsd schema itself. Therefore, for a base/standard glue2 profile, only these standard elements are considered when validating, i.e. <element name="Service" type="glue:Service_t" substitutionGroup="glue:AbstractService"/> <element name="ComputingService" type="glue:ComputingService_t" substitutionGroup="glue:AbstractService"/> <element name="StorageService" type="glue:StorageService_t" substitutionGroup="glue:AbstractService"/> <element name="Endpoint" type="glue:Endpoint_t" substitutionGroup="glue:AbstractEndpoint"/>
However, if a new service or endpoint specialisation needs to be defined in the future, the relevant working group can simply define a new (service and/or endpoint) element in a new extending schema and specify the appropriate substitution group (as per the glue2gocdbExtensions.xsd example - is an example only). This extension schema can then be profiled within OGF for example. Importantly, by using the xsd:substitution groups, any new Service and Endpoint elements can be validated as part of a glue2 AdminDomain (e.g. this registry supports the glue2.xsd base profile + 'ServiceX1' from the 'X1' extension profile document). In doing this, no changes are required in the base glue2.xsd.
what's exactly wrong with the current schema when it comes to extend it? can you elaborate a bit more?
See above explanation.
I also have another question (i am not so much into XML): with your approach, would be also possible to override/overwrite attributes and types belonging to a superclass? (i.e. rewriting AbstractService Capabilities?)
Any element that extends the AbstractService or AbstractEndpoint *has* to implement the elements/attributes defined in the appropriate base types glue:Service_t and glue:EndpointBase_t (otherwise XML validation will fail - the base type elements/attributes cannot be overridden). Of course, the sub-type specialisations can define their own elements and attributes but these will be defined (correctly) in a different namespace.
Hi Stephen, I am making a proposal about the XML rendering only. The EgiGocdb stuff is just an example of how to extend the modified glue2.xsd (i am not suggesting the EgiGocdb stuff is considered, just the modified glue2.xsd).
Thanks David
-----Original Message----- From: Burke, Stephen (STFC,RAL,PPD) Sent: 13 April 2012 16:20 To: Meredith, David (STFC,DL,ESC); glue-wg@ogf.org Subject: RE: [glue-wg] proposed changes to glue2 XSD
glue-wg-bounces@ogf.org [mailto:glue-wg-bounces@ogf.org] On Behalf Of david.meredith@stfc.ac.uk said:
- glue2GocdbExtensions.xsd (A schema that imports glue2.xsd and extends
AbstractService and AbstractEndpoint elements in order to define custom Service and Endpoint specialisations. These custom sub types inherit from
On 04/13/2012 05:40 PM, david.meredith@stfc.ac.uk wrote: the the
base abstract elements).
I'm a bit unclear if you're just making a proposal about the XML rendering, or if you want to add your new specialised classes to the official GLUE 2 spec. If the latter, I think "EgiGocdb" is a slightly clumsy prefix - I wonder if we could think of some more generic name like MonitoredService/Endpoint, since the things you're adding don't seem to intrinsically be all that GOCDB- specific.
Stephen
-- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project _______________________________________________ glue-wg mailing list glue-wg@ogf.org https://www.ogf.org/mailman/listinfo/glue-wg
-- Florido Paganelli Lund University - Particle Physics ARC Middleware EMI Project