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


Help: OASIS Mailing Lists Help | MarkMail Help



   SAX2: NOTATION attribute decls

[ Lists Home | Date Index | Thread Index ]
  • From: David Brownell <david-b@pacbell.net>
  • To: xml-dev@xml.org
  • Date: Mon, 06 Mar 2000 07:53:21 -0800

I don't remember where I mentioned this before, but the issue is still
unresolved so it needs to be raised again ...

The problem is that the DeclHandler.attributeDecl() callback doesn't show
what the permitted values for a NOTATION attribute are.

To recap, there are two types of enumerated attributes in XML, and NOTATION
attributes are one of them.  The difference between these two declarations:

  <!ATTLIST elementType aNotation NOTATION (png | jpg | gif) #REQUIRED>
  <!ATTLIST elementType anEnumeration      (png | jpg | gif) #REQUIRED>

from the XML perspective is that [a] in the former case three notations
("png", "jpg", "gif") must first be declared, and [b] there may only be one
NOTATION attribute per element.  (The latter is courtesy of a new erratum,
which says in effect that NOTATION attributes suggest classes, not types,
for the elements with which they're associated.)

>From the SAX2beta(2) perspective, the callbacks look different:

  attributeDecl ("elementType", "aNotation",     "NOTATION",
	"#REQUIRED", null);
  attributeDecl ("elementType", "anEnumeration", "(png|jpg|gif)",
	"#REQUIRED", null);

Information is clearly lost.  Layered software can't test restriction [a],
or the constraint that any value which is provided for that attribute be
one of the permissible ones.

This matters when working with DTDs, such as Docbook, that use NOTATION

How to fix the NOTATION decl problem?  Two solutions come quickly to mind:

	(1) There could be distinct callbacks for enumerated and
	    non-enumerated attributes.  For example, passing an
	    array of permissible values for enumerated values.

	(2) Pass an ugly string like "NOTATION(gif|png|jpg)" for
	    the notation type.

Were I doing this from scratch, (1) would certainly be my choice.  In
fact that's what I did with Sun's parser about 16 months ago, based on
the earliest SAX2 discussions on record.  But at this point, (2) might
be the expedient fix to SAX2 (given the impetus to call it "done" ASAP).


- Dave

This is xml-dev, the mailing list for XML developers.
To unsubscribe, mailto:majordomo@xml.org&BODY=unsubscribe%20xml-dev
List archives are available at http://xml.org/archives/xml-dev/


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

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