Re: Proposed DTD Names, Structure [Was: HTML 2.0 editing status ]

Eduardo.Gutentag@Eng.Sun.COM (Eduardo Gutentag)
Date: Wed, 7 Sep 94 12:30:57 EDT
Message-id: <9409071629.AA16697@rug.Eng.Sun.COM>
Reply-To: Eduardo.Gutentag@Eng.Sun.COM
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: Eduardo.Gutentag@Eng.Sun.COM (Eduardo Gutentag)
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: Proposed DTD Names, Structure [Was: HTML 2.0 editing status ]
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
>  
>  Proposal 1: Eliminate the HTML.Obsolete, HTML.Proposed, and HTML.Prescriptive
>  	marked sections	in the DTD -- leave the Obsolete stuff in,

Yes - but making sure its usage is deprecated

>  	and take the Proposed and Prescriptive stuff out. The net effect
>  	on the grammar defined by the DTD would be nothing.
yes
>  
>  
>  Proposal 2A: Keep the public identifiers as-is:
>  html-0.dtd:     "+//ISBN 82-7640-037::WWW//DTD HTML Level 0//EN//2.0"
>  html-1.dtd:     "+//ISBN 82-7640-037::WWW//DTD HTML Level 1//EN//2.0"
>  html.dtd:       "+//ISBN 82-7640-037::WWW//DTD HTML//EN//2.0"
>  
>  Proposal 2B: Replace them with an unregisterd FPI, naming IETF as the owner:
>  html-0.dtd:     "-//IETF//DTD HTML Level 0//EN//2.0"
>  html-1.dtd:     "-//IETF//DTD HTML Level 1//EN//2.0"
>  html.dtd:       "-//IETF//DTD HTML//EN//2.0"
>  
>  Proposal 2C: Replace them with an registerd FPI, naming IETF as the owner.
>  	This requires that the IETF register itself somehow with ISO.
>  html-0.dtd:     "+//IETF//DTD HTML Level 0//EN//2.0"
>  html-1.dtd:     "+//IETF//DTD HTML Level 1//EN//2.0"
>  html.dtd:       "+//IETF//DTD HTML//EN//2.0"
>  

2C if IETF does register itself, 2B otherwise

>  
>  Proposal 3: Combine html-0.dtd, html-1.dtd, html-2.dtd into one file,
>  	as per Terry's suggestion:
>  >My solution to the three-DTD problem is to fold -1 and .
>  >into -0, as marked sections, with the basic content models
>  >supplied with empty parameter entities that expand within
>  >those marked sections.  Then there's only one file named
>  >.dtd, and the IGNORE/INCLUDE operations are simple.  Example
>  >on request.
>  
Well, the majority seems to favor Terry's suggestion, and I can see
why; however, if I'm not mistaken, Dan's well thought out 3-dtd
solution was meant to address the issue of compliance at various
levels, and merging everything into one large dtd does not seem to
address this issue. 


*******************************************************************************
Eduardo Gutentag		Sun Microsystems Inc (SunSoft)
				AnswerBook Publishing/Online Information

e-mail: eduardo@eng.Sun.COM
Phone:  (415) 336-6916
fax:	(415) 336-4449  (e-mail notification please)

2550 Garcia Ave, MTV19-106, Mountain View, CA, 94043-1100

*******************************************************************************