Lists Home |
Date Index |
- From: Paul Prescod <firstname.lastname@example.org>
- To: John Cowan <email@example.com>
- Date: Tue, 9 Jun 1998 15:25:10 -0400 (EDT)
On Tue, 9 Jun 1998, John Cowan wrote:
> Without information on the names of valid entities and notations,
> and potentially without information on IDs, then ID, IDREF,
> ENTITY and NOTATION are indistinguishable; IDREFS, ENTITIES, and
> NOTATIONS also all look the same. The only remaining distinction
> is syntactic.
Well, XML is funny that way. Text entities are clearly physical. You
cannot refer to them in any official way in the logical structure at all.
But unparsed entities are probabaly more logical than physical. They can
only be used in attribute values. SAX can lead us here too:
notationDecl(String, String, String)
Receive notification of a notation declaration event.
unparsedEntityDecl(String, String, String, String)
Receive notification of an unparsed entity declaration event.
So NOTATION and (unparsed) ENTITY declarations are considered application
level information. ESIS also provides this information.
SAX provides information on ID/IDREF attributes, but I don't think that
ESIS did, so this is more debatable.
Anyhow, I wouldn't care much if we cut loose all of those types. I just
don't think that removing them is the natural extension of not checking
> Saying what the specific default value is or whether there is none
> is overspecific (the DTD must bear this information, and
> an XSchema would be either redundant or conflicting, a Bad Thing);
> the only three cases are: a) the value must be present and must
> be "foo" (#FIXED), b) the value must be present but can be anything
> (#REQUIRED), or c) the value need not be present.
We might not need fixed attributes. A fixed attribute is merely an
attribute with a single choice. Can't that be represented directly as a
choice attribute with a single choice (yes, this implies that we would
open up "choice" attributes beyond names...any arguments with that?)
So that would allow us to reduce the "optionality" requirement to
"optional or required".
xml-dev: A list for W3C XML Developers. To post, mailto:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)