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.