In message <firstname.lastname@example.org>, Murray Altheim writes:
>>I'm glad to see this released, in whatever form.
>>It looks good, in general.
>Thanks. Still a lot to be done.
Sure. But now you'll get help! See:
My changes are attached below. Well... that was my first set
of changes. I've done another set to add INSERT and RESOURCE
>> * provide relative URLs as system identifiers, as well as
>> FPIs when linking from one piece of public text to another.
>> (for interoperability with stuff like SP, which groks HTTP
>> system identifiers)
>Isn't this handled in the SGML catalog file, external to the DTD? I'm under
>the impression that any system-dependent stuff should be external to the
>DTD, and that the SGML catalog file is where the mapping from PUBLIC
>external identifiers to system-dependent SOIs takes place. SGML Open's
>catalog definition does not provide for URL mappings, nor does the SGML
Yes they do. My point is that we should look at the web as one great
by SGML system; then URIs are system identifiers. Check out the way
nsgmls handles http: URIs as system identifiers. Works great. Try this:
nsgmls -m http://www.w3.org/pub/WWW/MarkUp/html-pubtext/catalog \
When I finish putting in the relative URIs, we'll be able to just do:
FPIs are only necessary if you want to change systems (e.g. from URI
space to the Mac file system).
> Don Stinchfield's paper "Using Catalogs and MIME to Exchange SGML
>Documents" addresses this and provides proposed solutions for those
>systems that don't understand URL SOIs.
Sure... the catalog is handy for when you want to copy stuff out of
the web and use it in the local filesystem.
> It's a great feature of SP, but not
>part of any specification as I understand things.
It's just part of SP's entity manager. Since relationship between and
entity manager and a filesystem, diskette, network, chalkboard, or
typewriter is unspecified, any of those mechanisms can be used to
build a conforming parser.
>> * Can we move the SDA stuff to LINK declaratoins at this point?
>> Or do we have to keep them in the ATTLISTs?
>I was only following what was in the original 2.0/2.1 document. If you have
>specific recommendations as to what needs changing, I'd be quite happy to
>incorporate your ideas.
Actually, since you made the stuff available, I'm doing a little hacking myself.
> I'm frankly unclear as to how SDA entities are
>used, so I don't know what changes would be needed.
Me too. That's why I want them separated out -- so the SDA-knowledgeable
folks can maintain them.
>> * Get rid of %HTML.Recommended stuff
> Perhaps switching in and out certain modules would
>allow for both within the same DTD. I've been planning on doing that with
>'%HTML.Hilighting' anyway, so maybe 'HTML.Recommended' is another
>candidate. Just a lot more work...
Modules seems like a good idea: choose these modules for a permissive
DTD, and these alternatives for a clean DTD. Rather than marked sections
in html.dtd, just have html-edit.dtd and html-browse.dtd.
> BTW, maybe this is the time to ask: why
>was the semicolon left off of '%HTML.Recommended' when used as marked
>section status keyword ('%HTML.Recommended' vs. '%HTML.Recommended;')?
Because it's optional -- it's only necessary to disambguate, e.g.
>>I'm curious about testing: I don't see any sample documents. Have you
>>done any testing?
>I'd just started installing nsgmls on a local system when I took a job in
>Cambridge, so I haven't had the time to complete and test.
Right.... I found a few typos...
>I'm not quite clear on this. Don't we really need a test of DTD
>equivalence, not document validation equivalence?
No. I don't want to reproduce the HTML 2.0 language. I want to find
out how the language has evolved -- how people are using it.
That's what the validation service was set up for -- so folks could
give feedback of the form "the DTD doesn't allow for this perfectly
reasonable looking document: ..."
>Documents produced by an SGML compliant editor would by nature
>validate against the DTD used to produce them, so it seems that your first
>idea (using those documents riddled with errors) would be better.
There are authoring tools out there now, but they're still not SGML-based.
Documents produced by non-SGML authoring tools are likely to be invalid,
but only in a finite number of ways that will be easy to catalog; contrast
this with the problem of cataloging the noisy errors that are made with
a text editor.
>In the content negotiation working group we're discussing HTML feature set
>negotiation. I'm considering changing the 'base' module name ('headings.*',
>'tables.*') to include ownerID ('ietf-html-v2.2-headings.*',
>'w3c-html-v2.0-ext-tables-v0.3.*'), so that there's a direct link between
>HTML extension and feature negotiation based on a keyword.
Take that to an extreme, and module names become global names -- i.e.
URIs. That's what I'm after: pick and choose modules from all over the
>Thanks very much again for your comments.
Thanks for the DTD work!
* added color module (body colors, font colors, ..
* added dynsrc module
* added font module
* added layout module
(hr size, image align, etc.)
@@ need to document how these are all obviated by stylesheets
@@ invent a macro notation to formalize it?
* removed some funky marked-section stuff (%body.forms, %HTML.Recommended, etc.)
* changed content model for table to accomodate some test data I found
(@@ need to review this change with Dave etc.)
* genent module: These are parameter entities!
moved %just to layout.dtd
* Typos in comments in ISOlat1.sgm
* @@ my nsgmls doesn't have wide char support, so I had
to comment out much of the Unicode stuff
* got rid of all internal version lables (except
machine generated ones, using RCS keywords)
"status" is not a function of the info in
the file; it's a function of the world's perception
of that info. The status belongs in annotations
(ala PICS labels)
* Changed owner from IETF to W3C
@@ draft "minimal HTML" DTD (level 0)
@@ draft editing interchange DTD
@@ draft stylesheet-happy DTD
@@ specify DSSL-STTP based macro mechanism to allow architectural
forms that express the notion that
<font size="+3">xxx</font> equates to
<span style="font-size: +3">...</span>