Lists Home |
Date Index |
- From: John Cowan <firstname.lastname@example.org>
- To: email@example.com
- Date: Sat, 15 May 1999 20:14:29 -0400 (EDT)
I want to thank the Schema WG for its hard work, and I realize that
the following long list of comments can't be attended to right away,
but I hope you are able to get to them all eventually (preferably
by doing exactly what I want :-)).
Note in clause 2.2: validation does not in fact contribute anything
to the infoset. The things you mention (default attributes,
attribute value normalization) are done by all processors whether
validating or not, provided the relevant declarations appear in
entities read by the processor. Non-validating processors are
licensed not to read external entities, but not to ignore declarations
in entities that they do read.
elt-default: I think defaulted content is a fine idea.
sic-elt-default: I agree with the "Preferred solution".
namespace-declare (not speaking officially for infoset wg here):
The trouble with making xmlns:foo attributes part of the infoset
is that that locks in the name "foo", which is in effect a prefix
and supposed to be changeable without affecting schema validity.
I suggest you find a way to work around this problem.
Clause 3.4.5: I associate myself fully with Paul Prescod's comments
on removing the restrictions on mixed content: #PCDATA should be
just a token, and whitespace where an element is expected simply
doesn't affect validity.
Definition of "full name" is very hard to understand. Please reword.
Note in clause 3.4.9: I think any notion of implicit names is bogus.
Please allow only explicit names.
The "transclude" example: I don't think XLinks do transclusion, so a
better name should be used.
Clause 3.6: I associate myself with all others who denounce entity
declarations in schemas, especially if they are allowed to satisfy
otherwise unsatisfiable XML 1.0 entity references. Including them
simply to superset DTDs perpetuates a design error made decades ago.
Furthermore, nearly-well-formed XML is simply not XML, and XML
WGs don't have any mandate for providing standards relating to
Clause 4.2: It seems strange to have an "export" element which exists
(due to the default) primarily to declare what is *not* exported.
Also, scattering individual export declarations through the schema
in imitation of Java seems to me a mistake. I prefer the Common Lisp/Ada/
C++/etc. style where nothing is exported by default and where all
*specific* objects to be exported are declared at the top of the schema.
Clause 4.7: it would be useful to allow, at user option, schema processors
to signal an error in case of a declaration conflict, instead of just
ignoring all but the first. Conflicts may be the result of design
errors rather than intentional overriding.
Clause 4.8: the wording is bad here. "URI" means "URL or URN".
If an URL is a string, so is an URI; if an URL is an abstract reference
to what the string references, so is an URI. Calling a resolvable
pointer an URL, and a potentially unresolvable one an URI, doesn't
fit the facts.
Clause 5: I propose that documentation be permitted as the first
(optional) child element in every declaration, in the form of an
"xhtml:body" element. XHTML, though not yet a Rec, is probably stable,
and any instabilities reflect unintended discrepancies with HTML 4.0.
Clause 6.1: The term "RUE" no longer appears in the Infoset-WD.
Use "reference to unknown entity" instead. Better yet, demand that
schema-validators must read all external entities, so that RUEs
(by any name) are no longer an issue.
I may have comments on the schema-schema or the schema-DTD later.
John Cowan firstname.lastname@example.org
e'osai ko sarji la lojban.
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)