Martin's comments on Namespaces in XML

The following are my comments on

    Namespaces in XML
    -----------------


First of all, I have to say that I didn't find any i18n issues,
which is really rare :-).


- There should be a link to potential errata (and ideally also
  to translations).

- "Acknowledgements" and "References" shouldn't be numbered as
  appendices. They should go unnumbered, similar to the Abstract
  or the table of contents.

In 1. Motivation...:
  
- "applications of Extensible Markup Language" ->
  "applications of the eXtensible Markup Language"

- "to avoid clutter": Change to a less colloquial expression.

- "not allowed in names, so cannot" -> "not allowed in names,
  and therefore cannot".

In 2. Declaring...:

- "are defined not here but" -> "are not defined here but"

- "NSC": Explain this abbreviation before it is used
  (currently, it is not explained, and only much later does
   the informed reader get a chance to infer that NSC may
   mean "namespace constraint").

- "It is not a goal that it be directly usable for retrieval":
  This sounds very close to "It is a goal that it be not directly
  usable for retrieval". I think this is not what's meant.
  I would prefer this to be written "It is not required that..."
  or "It is not necessary that...".

- [Definition]: Definitions of e.g. a term A usually have that
  term A very close to the start of the definition. For several
  "definitions", that's not the case, the defined term appears
  only in the second half of the definition. Please move the
  term to the beginning, or remove "definition".

- Some examples, in particular ecommerce.org, look surprisingly
  real. A comment saying that all the namespaces in the examples
  are hypothetical should be added.


4. Using Qualified Names

- urn:Connolly:input:required needs fixing :-). I'm not sure
  that we can say that it is bound to a namespace, because:
  - that namespace may change in the future
  - things with xml: as a prefix may by definition behave
    differently from usual namespace things.
  It may therefore be preferable to say that things prefixed
  with xml: have special meanings described by the XML specifications.

- The paragraph starting "This constraint may lead..." is difficult
  to understand. It should be reworded.


5. Applying...

- The comment "everything here" is misleading, because we are actually
  not in the html namespace on the line the comment appears. It should
  be changed to "everything from the next line on". Similar for
  other comments. Also "drop the default" is colloquial, and not
  easy to understand.

- In the first and third example, </html:html> should be indented by
  two spaces less than it currently is.

- "the governing RFCs for which contain rules...": The rules for
  URI equivalence are given in RFC 2396. It is unrealistic to
  expect from an XML namespace application to know all the
  possible additional lexical equivalences that might be defined
  for each scheme. The text should not give the impression that this
  is the case.

- The rationale for making the line <good a="1"     n1:a="2" />
  legal is completely unclear, and not obvious from the rest.
  It may be related to the distinction between global and
  per-element attributes, but having the same attribute twice
  should be as much a problem if they are two global ones
  as well as if one of them is "per-element", because the
  semantics of the attribute should be the same, and the
  distinction between global and per-element will in many
  cases be unclear.


6. Conformance

- The two first paragraphs, which serve as conformance clauses,
  should be written the same way, ideally starting with a short
  sentence and then listing all the conformance conditions in
  a bullet list.


Appendix A:

- The second example shows a use of the html:class attribute
  that should not be promoted. The class attribute should not
  be used for pure styling names such as "largeSansSerif",
  but for more content-related categories. While we cannot
  prohibit anybody to use html:class in this way, we should
  not promote it in examples. I'm sure that a better example
  can be found. The comment "which is used to achieve CSS
  formatting effects" is particularly dangerous.

- "are defined, in this namespace, to be global": This seems
  to require that an attribute is explicitly defined as global.
  As said above, the rationale for this is difficult to understand,
  in particular because we do not yet have a mechansim for such
  a definition.

- "Per-Element-Type Partition" -> "Per-Element-Type Attribute Partition".

- "has an associatied namespace in which appear the" -> "in which the ...
  appear" (this isn't German, or is it?)

- The choice of "type" as attribute in "ExpEType" is somewhat
  unfortunate, as "type" has a lot of connotations. I think it would
  be better to use attribute names in synch with the syntax,
  i.e. "prefix" and "localPart", and to streamline the attributes
  of "ExpEType" and "ExpAName".

- The last clause of A.4, in particular the mention of "child elements"
  is very difficult to understand (it looks to me as if the mention
  of "child elements" is out of place).


References:

- For the purposes URNs are referenced here, there are probably
  more adequate documents than the URN syntax document.

- The "ed." and "eds." usually goes *after* the list of names,
  and in case of RFCs and specifications is rarely mentionned
  at all.


General:

- There should be some comment that where backwards-compatibility
  with XML 1.0 (and also with CSS2 and maybe other specs) is desired,
  elements should be consistently prefixed.


Regards,   Martin.

Received on Monday, 5 October 1998 04:08:40 UTC