[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: ATTN: Please comment on XHTML (before it's too late)

  • From: David Megginson <david@m...>
  • To: XMLDev list <xml-dev@i...>
  • Date: Sun, 29 Aug 1999 14:43:01 -0400 (EDT)

Re: ATTN: Please comment on XHTML (before it's too late)
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>
   element.

4. Three separate JavaScript if statements to locate an HTML <form>.

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

-- 
David Megginson                 david@m...
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
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@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.