Please allow me to turn the questions around...

Rick Jelliffe wrote:
>  
>  From: "james anderson" <james.anderson@[...].de>
>  
>  > I agree, that it is gratuitous to require that xmlns:* attributes be declared for an ele
ment to be valid.
>  
>  Is there any need for explicit namespace declarations in the DTD at all?
>  

Are there reasons to require declarations in addition to those already required for document
 validation?

Are there reasons to ignore for purposes of universal name assignment those declarations whi
ch are likely to be present as
default value declarations?

>  Why not just assign whole element sets to a namespace, in the external DSDL framework,
>  and leave the syntax of DTDs exactly as it is?

Why not use the existing DTD syntax to assign namespaces to whatever portion of the element 
declaration set one needs to?

>                                                  That would seem to be more manageable,

That would parallel the effect of declarations within the document entity.

>  because then people can use their current non-namespace DTDs without needing to change
>  them.  And it would be easier to make GUI tools for too, which is a definite consideration
 IMHO.
>  
>  Namespaces were designed for modularity, so I don't believe there is any urgency
>  to support arbitrary mixes of namespace declarations in the same entity.

Namespaces were designed for modularity, so it is urgent that an extended DTD notation and/o
r interpretation support the same
mix of namespace declarations as is permitted for the document entity. One of the ostensible
 reasons for schema notations
alternative to DTDs was to contend with synonymy/homography issues. Extended DTDs must conte
nd with these issues as well. Any
changes to DTD interpretation and/or notation must effect universal name assigments within t
he document definiton which are
analogous to those specified for the document entity. Declarations with indefinite scope can
not accomplish this.

>  
>  So you would have an element set for CALs, an element set for DOCBOOK, and an element
>  set for XLink. The framework document could have something like:
>  

So you could combine element sets by specifying the namespace assignments in a framework DTD
:

<!DOCTYPE mix [
 <!ENTITY % cals SYSTEM 'location of declaration' > 
 <!ATTLIST calsRoot xmlns CDATA '...namspace for CALS tables' > 
 %cals;
 <!ENTITY % docbook SYSTEM 'location of declaration' > 
 <!ATTLIST docbookRoot xmlns CDATA '...namspace for docbook' > 
 %dockbook;
 ]> 

 <mix>  <!-- ... --></mix>

>  
>  Whether this is part of the framework itself, or part of the method
>  of invoking a DTD as part of a DSDL pipeline, don't forget that
>  you do have this upper-level of XML-syntax available.

Don't forget that these are the same declarations as would be required for "normal" DTD-base
d validation.

>                                                         There is
>  probably some sweet spot with DTDs where if you have too many
>  kinds of declarations it puts more people off than it attracts: I would
>  expect to see namespace-aware DTDs being translated into RELAX NG
>  or XML Schemas by an implementation anyway, so in a way they
>  are really just an alternative syntax for easier transitioning.

Which means that any translation tools can already process them.

...

-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org> , an
initiative of OASIS <http://www.oasis-open.org> 

The list archives are at http://lists.xml.org/archives/xml-dev/

To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>