Lists Home |
Date Index |
- From: David Megginson <firstname.lastname@example.org>
- To: XMLDev list <email@example.com>
- Date: Sun, 29 Aug 1999 14:43:01 -0400 (EDT)
Paul Prescod writes:
> David Megginson wrote:
> > As a developer, I believe that this is a seriously broken idea:
> > we need a single HTML Namespace URI so that we can identify and
> > process HTML markup embedded in other document types; if we have
> > to check three or more qualified names just to figure out that we
> > have an HTML <p> element (and write three separate patterns in
> > XSL, etc.) then we're in serious trouble.
> I think that if the three different namespaces happen be
> interchangable for the purposes of YOUR process then it is YOUR
> responsibility to say so.
That violates the basic rule of isolating complexity: if 99.9% of
processes will need to treat the three XHTML Namespaces as equivalent
(and I think that Tim's throw-away number was, if anything, a gross
underestimate -- I cannot imagine even 1 in 1000 processes caring
about the difference between transitional and strict), then it is
unjustifiable to force each process to manage the equivalences itself.
Do we really want to force everyone who does anything with HTML to
create the following?
1. Three separate XML queries to find an HTML <cite> element.
2. Three separate XSL patterns to format an HTML paragraph.
3. Three separate search patterns to the word "Prescod" in an <em>
Even if there is, some day, a top-level equivalence-mapping feature,
people would still be forced to define the top-level mappings.
It's all well blithely to state that dealing with this problem is the
application's responsibility, but there needs to be a *very* strong
justification for forcing this amount of complexity on the entire Web
community, and I haven't heard it.
> They are trying to do the right thing.
The sad part is that they did do the right thing in the last public
Working Draft, and then backpedalled suddenly.
You and I, Paul have seen too many worthy specs fail completely
because of superfluous complexity -- HyTime, Topic Maps, and DSSSL
(and Architectural Forms) spring immediately to mind, but they hardly
stand alone. Most specs fail anyway, complex or not (XML's success is
the exception rather than the rule), but it would be nice to give
XHTML at least a fighting chance.
All the best,
David Megginson firstname.lastname@example.org
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)