OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Entities in XSchema

[ Lists Home | Date Index | Thread Index ]
  • From: Paul Prescod <papresco@technologist.com>
  • To: John Cowan <cowan@locke.ccil.org>
  • 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 
text entities.

> 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".

 Paul Prescod

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:majordomo@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)





 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS