Lists Home |
Date Index |
- From: Ann Navarro <firstname.lastname@example.org>
- To: "Simon St.Laurent" <email@example.com>, "XML-Dev Mailing list" <firstname.lastname@example.org>
- Date: Mon, 30 Aug 1999 11:01:36 -0400
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
>>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
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
Modularization brings it's own namespace issues to the table. More on that
when the next draft becomes public.
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:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)