I'm back from vacation and ready to rock 'n roll...
>
> OK folks... we need more input on this than just Terry and myself:
>
> Proposal 1: Eliminate the HTML.Obsolete, HTML.Proposed, and HTML.Prescriptive
> marked sections in the DTD -- leave the Obsolete stuff in,
> and take the Proposed and Prescriptive stuff out. The net effect
> on the grammar defined by the DTD would be nothing.
I agree with getting rid of the marked sections -- evil, nasty things!
But I am still confused about keeping the Obsolete stuff in.
I guess that I really don't have strong feelings about XMP or LISTING,
so I am happy to accept the majority opinion.
> 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"
I think that 2B or 2C are both preferable to 2A.
Registration should be attached to IETF [or even WWW Org.]
For most applications, there will be no effective difference
between 2B and 2C so long as both/either are recognized.
Ideally, an FPI registered to IETF is needed.
> 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.
Ooh! Nasty, evil marked sections again. In this case, the
benefit outweighs the cost. A single file will be far easier
to manage, understand and maintain.
Murray
> Background...
>
> In message <199409051826.LAA06383@rock>, Terry Allen writes:
> >|
> >| In message <199409031449.HAA06296@rock>, Terry Allen writes:
> >| >
> >| >The DTDs don't parse together without generating errors
> >| >about duplication.
> >
> >| Could you give some details? I agree that the usage of the
> >| varous DTD fragments is underdocumented, but when used as intended,
> >| they produce no warnings nor errors for me. Try the html validation
> >| service, for example.
> >
> >I'm using sgmls -degruv and for html-0.dtd I get:
> >
> >sgmls version 1.1
> >sgmls: In file included at litl, line 1:
> > Warning at ./html-0.dtd, line 114 in declaration parameter 4:
> > Duplicate specification occurred for "%block"; duplicate ignored
> >sgmls: In file included at litl, line 1:
> > Warning at ./html-0.dtd, line 245 in declaration parameter 4:
> > Duplicate specification occurred for "%html.content"; duplicate ignored
>
>
> So don't use the -d flag of sgmls. That flag causes sgmls to warn about
> complete legal, standard idioms. It may be useful for debugging or some
> such, but those warnings do not indicate any non-standard or ill-defined
> behaviour.
>
> >and if you look at the DTD you see that
> >
> ><!ENTITY % block "P | %list | DL
> > | PRE | BLOCKQUOTE %block-2">
> >
> >is defined at l. 114, but above,
> >
> ><![ %HTML.Obsolete [
> > <!ENTITY % block "P | %list | DL
> > | PRE | XMP | LISTING
> > | BLOCKQUOTE %block-2">
> >]]>
> >
> >however,
> >
> ><![ %HTML.Prescriptive [
> > <!ENTITY % HTML.Obsolete "IGNORE">
> >]]>
> >
> ><!ENTITY % HTML.Obsolete "INCLUDE"
> > -- marks things that may disappear in future revisions -->
> >
> >so I'm rather confused, because
> >
> ><!ENTITY % HTML.Prescriptive "IGNORE"
> > -- marks things that may become standard in future revisions -->
> >
> >So we end up with the Obsolete and the normal entity definitions,
> >thus the warning. Something's amiss here, or I don't have the
> >right versions of the DTDs.
> >
> >I am also concerned that the target audience, developers without
> >much experience with SGML, will find these double negatives
> >troublesome.
>
> OK, so the logic is contorted. We still have not decided whether
> XMP and LISTING go in the HTML 2.0 DTD or not. This way, I can
> conveniently test either case.
>
> If there is consensus among the WG that these should go in, or
> that they should go out, I can edit the DTD and be done with it.
>
> The fewer marked sections the better, to me. Marked sections are
> like #ifdef -- evil.
>
> >
> >| I would take this declaration to mean "gimme the current version of the
> >| HTML DTD."
> >
> >But here we're defining 3 current versions.
>
> Right. To rephrase: "gimme the highest level of the current version of
> the HTML DTD."
>
> >| Anyway... it's just more convenient in practice to have something
> >| called html.dtd. Perhaps html.dtd should be a synonym (implemented
> >| as a symlink?) for a file called html-2.dtd.
> >
> >It may seem silly to continue flogging this horse, but then naming is
> >always contentious. There are lots of "HTML" DTDs floating around;
> >here we are setting everyone up for confusion if what we call the
> >HTML 2.0 DTD is called html.dtd *in a set that includes html-0
> >and html-1*. I should think HTML2.0.DTD would be about right.
> >
> >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.
>
> Go for it. For me, that would be a very expensive change. I have a
> whole test suite with Makefiles and such set up around these
> names. It's not a complex operation to change the names and structure,
> but it's tedious and time-consuming to Q/A them again. And renaming
> the CVS/RCS version control files is tedious. I don't see sufficient
> motivation to destabilize things so at this point.
>
> The filenames are arbitrary. The public identifiers are the names
> we should be bickering over. The ISBN... one I'm currently using is
> owned by Erik Naggum. In Tornonto, nobody seemed to like that idea.
> The sentiment was that the IETF should be the registered owner of
> the public text.
>
> And perhaps we should deistribute an SGML-Open style catalog
> file with the DTD.
>
> >| > Seems to me that if we're documenting current
> >| >practice (approximately) we can't very well mark anything
> >| >Obsolete,
> >| My view is that in fact, XMP and LISTING are obsolete in current
> >| practice. Their actual definition is not expressible in SGML, and
> >| they are only supported through backwards-compatibility hacks.
> >
> >I see that from the doc, but then to be strict about it they
> >can't appear in any DTD. Would it not do just as well to leave
> >them in and deprecate their use?
>
> Good idea.
>
> > Are we willing to say that
> >for Level 2 these elements may not be used at all? If not,
> >let's eliminate these marked sections. Proposed stuff should
> >fall into Level 1 or 2 or be eliminated.
>
> I agree. I just wasn't willing to zap things without consensus.
>
> >The use of Prescriptive might be avoided by making these changes
> >between versions of the DTD. As it stands now, these categories
> >(Proposed, Prescriptive) crosscut the 0, 1, 2 DTD structure,
> >making it possible to have Level 1 with or without Prescriptive,
> >etc. Let's collapse those categories into the 0, 1, 2 sequence
> >of changes, if possible. Then the only marked sections would
> >be the ones including Level 1 stuff and (within that) including
> >Level 2 stuff.
>
> I'm willing to get rid of Proposed and Prescriptive stuff by now,
> I guess. Things have been stable for long enough to "write it
> in stone" by now.
>
> >| Perhaps I could maintain a separate DTD for testing purposes, but
> >| I don't think that's a good idea, and I hope you don't either.
> >
> >I quite see your point, but the published DTD(s) don't need these
> >testing constructs if the point of the testing is to figure out
> >how to arrive at the published DTD(s). Or do you see this as a
> >useful feature, to be included in the published DTD?
>
> I guess we should decide out which way to flip the switches, and
> eliminate the marked sections. This seem pretty stable by now.
>
>
> Dan