[
Lists Home |
Date Index |
Thread Index
]
Please allow me to turn the questions around...
Rick Jelliffe wrote:
>
> From: "james anderson" <james.anderson@setf.de>
>
> > I agree, that it is gratuitous to require that xmlns:* attributes be declared for an element 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 which 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/or 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 contend with these issues as well. Any
changes to DTD interpretation and/or notation must effect universal name assigments within the document definiton which are
analogous to those specified for the document entity. Declarations with indefinite scope cannot 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-based 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.
...
|
