JRA1/SA1 Deliverable Review Form

Identification of the deliverable or milestone
Project: EMI Deliverable or milestone identifier: D5.5.2
Title: DJRA1.5.2 - Standardization Work Plan and Status Report Doc. identifier: EMI-DXXX-CDSREF-Title-vx.x
Author(s): A.. Konstantinov Due date: __

Identification of the reviewer
Name: P. Millar Affiliation: DESY EMI Activity/External project or Institute: JRA1/SA1

Review date 6/6/2011
Author(s) revision date mm/dd/yyyy
Reviewer acceptance date mm/dd/yyyy

Attach the reviewed document to the deliverable page, put here a link

General comments

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 (  
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 *


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*


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 

   * *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 

   * *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.



Additional general comments from 2011-6-6

This part of the review is for Chapters 1,2,4 and 5 only.

Overall structure and global comments

Please remove all usage of the word "actual" and "actually" in the document.

  • Morris: Done

Please use a uniform notation for EMI releases throughout the document: "EMI-1", "EMI-2", "EMI-3" and not "EMI1" or "EMI 1". When the document refers to an EMI release without direct context, this helps the reader understand that it is the release that is being referred to.

  • Morris: Done

The structure of the document in Chapters 3, 4 and 5 seems confusing .

From reading the titles, it seems that Chapter 5 describes the strategies that EMI is adopting to pursue standardisation. Chapter 3 describes the progress so far. Chapter 4 describes the plans for the remaining work.

If so, then a more natural structure would be:

  • Chapter 3 to describe the overall strategy (currently Chapter 5)
  • Chapter 4 to describe the progress so far (currently Chapter 3)
  • Chapter 5 to describe the planned work (currently Chapter 4).

Such a restructuring would also require moving some of the material currently in Chapter 5 into what is currently Chapter 4.

  • Morris: Not done: Discussed via e-mail that a structural change is not feasible given the limited time available. The re-structering can be performed after the review when the project has been re-structered as well (affecting the standardization task).

Chapter 1

This chapter provides a structural description of the document. There are various small changes in the document's use of English that would improve readability.

Section 1.2 describes the document's organisation. The part describing Chapter 1 states that the chapter explains the scope of the document; however this isn't done. Chapter 1 specifies the governance of the document (what is the update prodedure; who may updated it; etc). This isn't mentioned in Section 1.2.

  • Morris: Done: added governance

Several of the references in section 1.3 are missing corresponding URL; others are missing a title and have merely a URL. A consistent strategy should be used (e.g., a title + URL).

  • Morris: Done: a consistent strategy has been followed

Section 1.5 is missing a description for some terms used within the document; for example, DCI, OCCI, OVM, SIENA, SNIA and UVOS are mentioned in the document without reference and without the term being defined in section 1.5. The descriptions of the terms are limited to expanding the acronym; I suggest including a one-sentence description or a URL for further information (or including both).

  • Morris: Done: missing terms have been added; style of document, however across all work plans is without any further pieces of information

Chapter 2

Chapter 2 is the Executive Summary. An executive summary is a short document that should stand on its own. It provides the salient points from the document in concise form that allows someone to gather the key facts that the document's main body describes in depth.

In the current version of this document, I feel Chapter 2 fails to provide this separation. It makes several references to the documents structure (e.g., "After the status report, the document provides ..."). Some information is provided in a stand-along format; however, information may be hinted at ("the other five DCI project standardization roadmaps in particular" which five DCI projects? what road-maps?) or the reader is simply directed to the corresponding part of the document ("[..] we offer at the end of this document a conclusion [..]")

Since the executive summary is likely to be a starting point when reading the document; I suggest this chapter would benefit from work to remove references to the document's structure and ensure that all the key points from the document included.

  • Morris: Done: Reformulated addressing your mentioned points as best as possible

Detailed comments on the content

Given the limited time available, I've scanned in the comments and made them available from this location.

  • Morris: Not Done: Due to the review preparation and the deadline of sending the deliverable, these detailed comments couldn't be addressed and will be considered after the review

Additional recommendations (not affecting the document content, e.g. recommendation for future work)

Detailed comments on the content

Note 1: The reviewers must list here any observation they want to track explicitly and that require interaction with the authors
Alternatively all changes must be listed in the document itself using Word change tracking features (if you use Word)
Note 2: These comments have to be explicitly addressed by the authors and the action taken must be clearly described

N Page Section Observations and Replies Is Addressed?
1 xx x.y Sequence of comments and replies separated by twiki signature and date    

Any other modification, spelling or grammatical corrections, etc must be done directly in the document using tracked changes or similar mechanisms that allows the authors to identify which correction is suggested.

Edit | Attach | Watch | Print version | History: r4 < r3 < r2 < r1 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r4 - 2011-06-08 - MorrisRiedelExCern
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    EMI All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2021 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
or Ideas, requests, problems regarding TWiki? use Discourse or Send feedback