Re: Ending DTD proliferation at the W3C

I have a proposal to amend this: in cases where existing specifications 
include normative DTDs, then I think it should in some cases be OK to 
continue to publish and even update those DTDs as the specifications are 
revised.

Reason: those who adopted the technologies in question may have done so 
with the expectation that the DTD's would be usable with their tooling. 
Particularly if the spec updates are minor (perhaps not even directly 
affecting the DTD), I think it's reasonable for those users to continue to 
depend on tools that use the DTDs.

Other than that, I'm neutral or cautiously supportive of the proposal 
insofar as it impacts specifications as yet unpublished. Thank you.

Noah

On 1/13/2014 2:22 PM, Michael[tm] Smith wrote:
> In response to a suggestion[*] from Dan Appelquist on twitter, I'd like to
> ask that the TAG consider taking a position against further publication of
> DTDs in W3C TR space by any W3C working group.
>
>    [*] https://twitter.com/torgo/status/422746987650220032
>
> Specifically, I'd like for there to be a document from the TAG somewhere
> stating that:
>
>    - Working groups should not include DTDs or portions from DTDs in any
>      form, even non-normatively, within any specifications they wish to
>      publish as Working Drafts or Notes in TR space.
>
>    - Working groups should also not publish DTDs separate from specifications
>      in TR space, including not for the purpose of referencing the DTDs
>      within a specification nor for any other purpose; so for example, no
>      further DTDs should be made available in TR space similar to the way in
>      which http://www.w3.org/TR/html4/strict.dtd is made available there.
>
>    - No current W3C draft specifications that contain or reference DTDs
>      should be allowed to transition to Candidate Recommendation, Proposed
>      Recommendation, or Recommendation.
>
> The rationale for stopping publication of DTDs in TR space is that:
>
>    - DTDs published in TR space risk being considered by the community to be
>      complete normative expressions of the document-conformance constraints
>      for a specification, even if they are labeled as non-normative.
>
>    - DTDs as a formalism lack the power to express many document-conformance
>      constraints that can be stated in the prose of a specification. The
>      community should always first be reading the prose of the specifications
>      themselves in order to understand the conformance constraints the
>      specification states -- rather than relying on any accompanying DTD.
>
>    - To the degree that it's useful for the W3C to publish schema formalisms
>      at all, DTDs as a schema formalism have been obsoleted for many years
>      now by Relax NG and W3C XML Schema (which even themselves are unable to
>      express many conformance constraints that can be stated in the prose of
>      a specification, but at least come closer than DTDs).
>

Received on Tuesday, 14 January 2014 02:58:11 UTC