Minor copy editing, resolving the easier points from my long mail:

p 1, title matter:
  Minimal version of my full address.

p 1, Sect I, col 1, bullet 1:
  Simpler formulation, and consistent plural.

p 2, col 1, paragraph 3 "Of course, NeXus strives ...":
  Deleted as overly redundant with what has been said in Sect I.

p 2, col 2, "provided by the NeXus class name":
  Indicated that this is realized as a HDF5 attribute.

p 3, Sect IIIA2, bullet 1:
  "The array's first dimension is the number of ..." Categorically
  impossible, a dimension (meant here in the sense of axis, not of
  rank) can contain a given number points, but it "is" not a number.
  Corrected into "The array's first dimension is the scan axis."

Same subsection, last sentence:
  Deleted spurious "is" from "is behaviour is".

p 4, Sect IV, paragraph 1, line 5:
  "possible" -> "allowed"

p 4, Sect IV, paragraph 1, lines 11:
  "names" -> "keywords to designate groups and fields"

p 4, Sect IV, paragraph 1, lines 12-13:
  "for all the names in a NeXus base class"
  -> "for all allowed keywords".

p 4, Sect V, paragraph 1, sentence 4:
  Deleted as fully redundant.

p 5, Sect VII:
  Changed to avoid calling some facilities "relevant", which sounds
  unfriendly towards the others.

p 5, Sect VIII:
  Deleted void statement "still exists and".

p 5, Sect IX, last sentence:
  Changed. No longer suggest one might hesitate to consult a WWW-site.

p 5, Ref 1:
  Reformatted like a regular journal reference.

14 times:
  "HDF-5" -> "HDF5", which seems to be the official form.
Rewrote the first to paragraphs of Sect II in order:
- to avoid the unclear notion of a NeXus user,
- to make clear that "only one file" refers to one measurement,
- to explain the paradox of non-NeXus data in a NeXus file.
Rewrote last paragraph of Sect II,
 trying to resolve the following problems with v5:

Two things are mixed:
  - A raw data file may contain some entries that are not needed
    for data analysis (but maybe valuable for long-term documentation
    of the used instrument, or for organisational purposes: for
    instance, the names of the experimentalists clearly belong into
    a raw data file, but are not needed for data analysis).
  - NeXus foresees many different types of fields, of which any
    given instrument only uses a subset.
The numbers 100 and 20 are too arbitrary. The paragraph is
  not yet convincing as a rationale for application definitions.
Trying to explain why NXmonuitor is not at the same level as NXdetector:
if it's an historical accident, then better say so instead of letting
things appear more complicated than they really are.
Move the requirement of default visualization to Sect I,
and simplify the pertinent paragraph in Sect IIIA1 accordingly.
Even simpler.
consistent orthograph x-ray
Treat multi-method instruments in a clearer and simpler way.
Omit confusing sentence about undefined behavior.
Explain how the type descriptor is encoded in HDF5.
Set all NX keywords in special font.
Revise Sect IV:
- avoid the term "NeXus dictionary" (to avoid confusion with our description
  of base classes as dictionaries, and just to save a term that is not
  reused elsewhere)
- clearly distinguish "base class" and "base class name"
- give a simpler explanation of what a base class is
- use "data field" as a term that comprises simple data types and subgroups
- say explicitly: there is no mechanism to mark keywords as obligatory
- mention that NeXus does not specify the rank of data fields
Move remarks about changing base classes or submitting application definitions to the Governance section.
More text moved to governance section.
Revise beginning of Sect V: what's an application definition.
Say it once, but concisely.
Merge pull request #1 from jwuttke/master

Various modifications, in response to my own criticism