SVG and XHTML: Request for nonconflicting names

[please note that this has been cross-posted to both the HTML 
and SVG working groups]

Andrew/Chris,

This message is a recommendation on avoiding name clashes between 
document types which are assumed to commonly be used together, such 
as MathML + XHTML, SVG + XHTML.

When mixing element types from multiple DTDs (or 'namespaces') in a 
WF XML document, the use of colonized names eliminates name conflicts.
This is an adequate solution for well-formed documents, but currently
there is no specified means for validating compound XML documents.

An alternative that currently works within the framework of XML 1.0 is
to create a 'hybrid DTD' (ie., a new document type) by combining the 
markup declarations from two or more DTDs into a single DTD. The 
modularization efforts within the HTML working group aims at expediting
this, but when creating such a DTD, there cannot be element type or 
parameter entity name conflicts between the two DTDs. The latter can 
be altered without changing the original document model, but name 
conflicts on element types introduces the need for colonized names 
within the DTD itself.

Use of colonizing names within a DTD means that the document type 
defined by such a DTD is not itself useful as a namespace, as there 
is no allowance for hierarchical namespaces (eg., <A:B:C>), and one 
cannot rely on any type of defaulting within the DTD as (at least 
in theory) one can in a document instance.

For this reason, I would recommend that anyone developing a markup
language whose requirements include usage within an HTML (or rather,
XHTML) document -- where creation of a hybrid DTD is desired -- that
steps be taken to avoid element type name conflicts. Name conflicts 
may include:

  Element types:
      Conflicts in element type names between DTDs cannot be
      resolved without: (a) removing the offending element types;
      (b) changing the element type names; or, (c) colonizing
      the names within the DTD. The first two break the markup
      model of the altered document type. This may be acceptable
      in some circumstances. Item (c) as stated above is an
      acceptable solution, but really only for validation, not
      for authoring. And it prohibits the resultant DTD from 
      itself being used as a namespace in compound XML documents.
      What I'm suggesting is that if a design team knows beforehand
      that their DTD will be used in conjunction with an existing
      one (in our case, XHTML, whose names are constricted to those
      in HTML 4.0), that it behooves them to avoid element type
      name conflicts.
      
  Attributes:
      Because attribute specifications are always attached to a
      specific element type, there should not be any difficulty
      here. But given that many attributes are declared 'globally'
      within a DTD, care should be taken to avoid declaring such
      attributes using different types or values. For example,
      a 'class' attribute may exist in both source DTDs, with
      it declared as CDATA in one, as NMTOKEN or an enumerated
      list in another. While the parameter entity conflicts 
      must be dealt with by the developer upon merging, these
      types of conflicts may be problematic in application design.

  Notations:  
      Any overlapping declarations would assume to be merged
      ('GIF' is probably the same in both, but if not, a 
      different notation name should be chosen). If the ExternalId
      of the two is different, the designer should be given 
      assistance on which one is the correct one to use in 
      the application-specific environment.

  Parameter Entities:
      While in theory, these can be fixed by implementors when
      merging DTDs, in practice I believe designers should avoid
      such name conflicts. If conflicts exist in merging with
      XHTML, it would be helpful to note these conflicts in some
      documentation so that they can be suitably changed. Because
      such conflicts are difficult to discern, care must be taken.
      I am considering releasing a simple (and rather stupid) Java
      tool I've written to catch name conflicts between DTDs.
      
  General Entities:
      While apart from character entities, it is unusual to find
      general entities defined in a DTD. There is no good way to
      fix name conflicts except documentation. As for character
      entities, again, it should be noted. I assume most use of
      named character entities will be ISO-based ones, so hopefully
      name conflicts will be avoided.
   
In MathML, there are two element type name conflicts (var and select).
It is a sad state of affairs that because of this, it is impossible to
create a hybrid DTD combining XHTML plus MathML. Because this could have
been so simple to avoid, I am making this recommendation to the SVG working
group so that a similar circumstance does not arise.

Thanks for your consideration,

Murray

...........................................................................
Murray Altheim, SGML Grease Monkey         <mailto:altheim&#64;eng.sun.com>
Member of Technical Staff, Tools Development & Support
Sun Microsystems, 901 San Antonio Rd., UMPK17-102, Palo Alto, CA 94303-4900

              An SGML declaration does not an i18n make.

Received on Wednesday, 17 March 1999 12:24:56 UTC