[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)
David Megginson wrote: > > It's going to be brutal just getting people to create well-formed > XHTML documents and to include the Namespace declaration; getting > software developers to recognize all three XHTML Namespaces (even if > doing so requires only a three lines of code) will be all the more > difficult, and introduces three times the opportunity for bugs and for > interoperability problems because of omissions. Adding three lines of code introduces the opportunity for three times the bugs in a real application? I don't buy it. Looking for "HTML 4.0 strict" OR "HTML 4.0 frameset" is no harder than looking for "UL" OR "OL", if the software is set up right. And it is *just as necessary in the general case*. There will be tons of code that needs to work the same across "similar" element types across namespaces. > This will be the third time that I've mentioned that I agree that some > sort of versioning is useful. Most processors won't care most of the > time, so the versioning shouldn't take a form that makes their life > harder, but what's wrong with a 'version' attribute in the HTML > Namespace? Processors that don't need it can ignore it, and those > that do need it can still get the information they need. Your presumption is that most processors won't need it. My presumption is that most processors WILL need it. If you don't know that you are dealing with some future version of HTML, you also don't know if your code will work or crash. In the old HTML world we were content to fudge it but in the new XHTML world we are supposed to be doing things in a robust manner. I think that we are both half right. Most software will not check the version number on the presumption that they do not need it and then they will silently fail when new versions of XHTML come around as many HTML 3.2 apps silently failed on HTML 4. That's the sociological problem. The technical problem with the version number solution is that it is HTML-specific. When I do a query to return nodes for processing, I need *in general* to know the types and versions of the element types of elements so that I know what I can expect as content and attributes. That means that I need a pervasive concept of element type versions. We could add this to XPath and XSL but eventually Occam's razor kicks in: how is the relationship between incompatible versions of HTML really different than the relationship between the relationship between Cold Fusion ML and DTML different than that between HTML 5.x and 4.x. In general, I need infrastructure that handles new versions without breaking old code. Backwards compatibility is arguably the most pervasive, persistent problem in XML system design. Paul Prescod 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! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|