Re: why distinctions within XHTML?

[originally posted to XML-dev]

At 11:01 AM 8/30/99 -0400, Ann Navarro wrote:
>If I'm going to write an XHTML editor (that's worth anything as an *xhtml
>editor* vs. just a plain text editor), I surely want to know whether the
>differences in what can occur in a <p> in strict vs. transitional. If my
>application doesn't know these differences, it can't provide appropriate
>options or indicate errors appropriately. 

It seems like DOCTYPE and the three DTDs should handle this without any
problem.  I can't figure out why you'd want to bring namespaces into this.
I could write an editor that recognized the namespace and did processing
based on the namespace, but I think DOCTYPE would be simpler.  I don't
think namespaces have to do this work.

(Of course, I'd be delighted to see something more powerful than DOCTYPE,
and have considered using namespaces to support it.  That doesn't seem to
be what we're talking about here, though.)

>If I'm writing an application that will parse XHTML documents, and
>apparently I only care that <p> is a structural container, then I suppose I
>don't care about the differences -- but even that reasoning escapes me, in
>that if I find <p align=center> when we're purporting to be XHTML 1.0
>Strict, then there's a problem. If you're only writing an app that cares
>about well-formedness, then I suppose you're ok. 

Again, the DOCTYPE declaration already takes care of this, and there
shouldn't be any need to use namespaces in conjunction with this
processing.  I could write the logic into the app using namespaces, but I
could just use the DTD to supply that logic instead.  Why duplicate DOCTYPE
with namespace declarations?

>Well-formedness in and of itself is great, but validation requires
>considerable more detail. 

Which is what DOCTYPE is for.  (Not to mention that namespaces and
validation is an unstable combination.)

>I want both my editors and processors to be aware of the constraints
>required when validating. 

So do I - but I don't think this requires namespaces.

>>It really reads like a badly thought-out grandfather clause foolishly
>>insterted into HTML a few versions ago.  Sometimes history is an anchor
>>dragging us down rather than a useful guide to the future.
>
>What reads that way? 

The whole concept of three DTDs for what is supposedly a single spec.  It's
nice to leave room for older concepts, but the price of three DTDs seems
high.  If we're going to have three, why not five?  Why not ten?  (John
Cowan's got an IBTWSH version of HTML I've applied quite successfully,
ignoring the W3C recs altogether.)

Maybe it's time to reexamine the valid/not-valid distinction we get out of
the XML 1.0 spec and start looking at more sophisticated 'weak validation'
like Rick Jelliffe's discussed.

>>Adding namespaces to an issue that's already of uncertain value seems to
>>generate enormous amounts of chaos.  Personally, I'd have like to see
>>namespaces used to indicate modules within XHTML - though I know that
>>presents large problems as well - not to identify different flavors of
>>XHTML itself.
>
>Modularization brings it's own namespace issues to the table. More on that
>when the next draft becomes public. 

At least that sounds promising!


Simon St.Laurent
XML: A Primer (2nd Ed - September)
Building XML Applications
Inside XML DTDs: Scientific and Technical
Sharing Bandwidth / Cookies
http://www.simonstl.com

Received on Tuesday, 31 August 1999 04:24:40 UTC