JRA1/SA1 Deliverable Review Form

Dear Morris, "EMI-PO"

Here is my review of DJRA 1.5.2, Chapter 3.  Given the time-scales involved 
the review is rather brief and I'm not sure how much of the suggestions can be 
implemented, if you choose to act on them.

First the high level view:

The document provides a good summary of the integration work during the first 
year of EMI.  I felt there were some unanswered questions after reading the 
document (see below) but they were few.

The document, chapter title and chapter contents seem to present a confusing 
description of what is the precise purpose of this document/chapter.  Is it to 
provide the work-plan and status report (as per the document title), the 
"status report" only (per the chapter title), or report on work done and 
current status (contents of chapter 3)?  Suggest updating titles to remove 
this ambiguity.

I found the document structure unfortunate.  Splitting the chapter into two 
sub-sections; the second sub-section into a sub-sub-section for each product 
and a sub-sub-sub-section for each standardisation theme results in a document 
that reads like a serialised spreadsheet rather than a coherent document.

Such structure also results in an excessive amount of copy-and-paste material.  
The same phrases or paragraphs appear under the same standardisation theme for 
different products.

Suggest structuring the document so that the chapter is split into sections, 
each describing a standardisation theme (GLUE 2.0, XACML, EMI-ES, StAR, ..).  
The status of each product would be described within this section, either in 
free form prose or in different sub-sections; either way, this would allow 
common information to be expressed without repetition.  The information 
currently located in the overview sections (3.1.1 and 3.1.2) and the 
interaction with external organisations section (3.1.3) would either fold into 
these standardisation-theme sections or would form additional top-level 
sections within the chapter.


   * *Morris: Not done: Re-structuring as discussed via e-mail will be performed later once the re-structering of the project is achieved*

The document uses several abbreviations for the same term: in 3.1.1.a) the 
terms "EMI-ES" and "ES" are both used for the "Execution Services"; later, 
both "OGSA-BES" and "BES" are used; "POSIX-based access", "POSIX-based I/O", 
"POSIX IO" and "POSIX/IO" are all used in in the one section (3.2.8.1).  
Please choose one form and use it consistently throughout the document.


   * *Morris: Done: I tried to be more consistent all over the document with these terms*



The term "Undone" is used throughout the document.  This is an unfortunate 
choice of term as the word can mean work has been done and subsequently been 
reverted (done then undone).  Suggest using "not start" or "not done yet" (or 
similar) instead.

   * *Morris: Done: changed term to not done*





Medium level points that apply generally

As mentioned above, there is a high level of copy-n-paste text.  Before going 
into specific points, here are some comments about the copy-n-paste text:


XACML conformance.

There is a stock two-sentence phrase used in several places describing XACML 
compliance.  There are two problems with this phrase:

This phrase fails to recognise that there are two issues here: that EMI-XACML 
profile is a valid XACML profile (does EMI-XACML conform to XACML?) and that the 
software product confirms to the EMI-XACML profile.  Whether EMI-XACML is a 
valid XACML profile is discussed by the two sentences whereas the latter (that 
the software conforms to EMI-XACML profile) seems to be left unspecified.

The description of how EMI-XACML is a valid XACML profile could be improved.  
The argument seems to hinge on conforming to some XSD; although, if so, then 
the description should make this clearer (NB. "schema" != "XSD" as there are 
several schema languages; also, "it" is vague in the first sentence).

However, I find XSD conformance not very satisfying since XSD is a rather weak 
schema language (c.f. RELAX-NG and Schematron).  I imagine it would be 
possible to write XML that is XSD conforming while not being valid XACML 
according to the English language documents describing XACML.

   * *Morris: Done: I added XACML XSD checking to make it more clear *




GLUE: XML vs LDAP.

The standardisation effort has mentioned adopting GLUE 2.0.  The CE-like 
components have adopted the XML rendering of GLUE 2.0 and storage has adopted 
LDAP rendering.  There doesn't seem to be any report of how these two 
renderings will interact; in particular, will the WMS need to speak GLUE2.0-
LDAP to storage systems and GLUE2.0-XML to CE components to do match-making?  
Will some component republish XML information as LDAP and visa versa?  These 
points are left vague by the document.

   * *Morris: Not done: ongoing discussions back and forth, no agreements and time-consuming, basically agreement is use both in parallel*




Some specific, medium-level points


3.2.3 WMS

In the summary table (at the end of the section) the GLUE 2.0 task is reported 
as "Adoption Status: Done".  This seems in contradiction with the earlier 
statement that the GLUE 2.0 task "was not achieved due to the delay .."

   * *Morris: Done: corrected*



3.2.4 UNICORE

Support for XACML is reported (in summary table) as Done; however, the 
description reads as if EMI-1 contains UNICORE with XACML that uses the 
UNICORE-XACML profile and not the EMI-XACML profile.  The work required to adopt 
EMI-XACML profile is described as "minor"; however, this suggests it hasn't 
happened yet, which seems in contradiction with the summary table's 
description of XACML task being "done".

   * *Morris: Not Done: good observation; in fact the summary is right since UNICORE adopted XACML itself since long, but not the profile - after the re-structering we need a finer granularity of the standardization table - that was not possible before due to lack of man power*



3.2.9 DPM

DPM POSIX I/O is marked Adopted Status "DONE" despite the description saying 
this has not yet been fully achieved.

DPM POSIX I/O conformance is marked "DONE" without stating how this was 
achieved.  The description beneath says "should be tested" indicating future 
work.

   * *Morris: Done: corrected*



3.2.10 FTS

The section describing the FTS project doesn't start at the top of a page.  
All other projects section start after a forced page-break.  Suggest FTS 
follows this convention.

   * *Morris: Done: adopted a uniform style*




3.2.13 Summary table

The definitions for "X" and "N" seem vague.  I guess "X" is for standards 
adopted before start of EMI and "N" is for standards adopted during the 1st 
year of EMI.  If so, the text should be updated to make this clearer.

If so, StoRM's POSIX-IO support, which is current described as "N", should be 
"X".

   * *Morris: Done: done - however the re-naming should wait after the review since the N and X are now in several documents and might confuse the reviewers if we adopt a new style now*




Low-level details.

The English is more or less sound.  The style is rather long-winded (too many 
words) and there are a few phrases that are difficult to understand with a 
single reading.  However, given the time constraints, I believe attempting to 
restructure sentences wouldn't be profitable.

There's a spelling mistake in section 3.1.1 c) "wihin" --> "within".  I didn't 
spot any other mistakes, but double-checking the spelling would be prudent.

Cheers,

Paul.