why distinctions within XHTML?

Ann Navarro ann at webgeek.com
Mon Aug 30 17:00:17 BST 1999


At 10:36 AM 8/30/99 -0400, Simon St.Laurent wrote:
>At 10:11 AM 8/30/99 -0400, Ann Navarro wrote:
>>At 10:12 AM 8/30/99 +0800, James Tauber wrote:
>>>However, as David Megginson and Tim Bray have argued, capturing the
>>>commonality between, say, "p" in each DTD is not just valuable, but pretty
>>>much vital.
>>
>>I think that the distinctions are just as vital, from the global
>>perspective, not just from an application developer perspective. 
>
>This may sound like a stupid question, but as I stated earlier I've never
>seen those distinctions as either useful or worthwhile.  

Well, to be honest, I've never really bought the argument that applications
are only interested in the commonality. 

Perhaps we need to define what type of application each speaker is
referring to. 

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. 

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. 

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

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


>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? 

>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. 

Ann

---

Author of Effective Web Design: Master the Essentials
Coming in September --- Mastering XML

Founder, WebGeek Communications            http://www.webgeek.com
Vice President-Finance, HTML Writers Guild http://www.hwg.org
Director, HWG Online Education             http://www.hwg.org/services/classes





xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)





More information about the Xml-dev mailing list