Discuss: Validating a Custom DTD
by J. David Eisenberg
- Editorial Comments
2 Nice with XML
I agread with Ryan ! This solution is realy interresting with the XML technologie (and not HTML)… unfortunatly, there are few server able to display HTML page as XML ! (it’s a pity because it’s not so difficult)
Just a small critic about the article itself, it were better to build your exemples with the XHTML 1.1 recomendation that is technicaly build to make such things. The modularization is an interresting way to customize DTD.
posted at 11:37 am on February 1, 2005 by Jeremie Patonnier
3 Why go this far looking for a validator?
To validate a custom DTD you don’t have to go searching for a stand-alone validator. You can still validate online. I’ve discussed it at [url=“http://aspnetresources.com/blog/xhtml_custom_dtd.aspx”]ASP.NET Cure: Custom DTD for XHTML[/url]. The Web Design Group validator handles custom DTDs just fine.
posted at 11:44 am on February 1, 2005 by Milan Negovan
4 Ok course
Of course, does your site validate against your own custom DTD.
But I thought, that the Idea behind that validating of your Online-Document against a public Schema should be, that we show, that we care for COMMON standarts.
As the local Part of a DTD possibly overwrites ANY element- or Attribute-Declartion with your original DTD and designing your own DTD gives you the same powers, anyone could add, modify or delete ANY Element or Attribute and still your documents validate perfectly.
As browser tend to ignore unknown tags and even allow you to style them with CSS everyone can happily design his own Markuplanguage.
This is, what the XML-idea was all about….
The only interesting question is:
“Are there any good reasons to create your docuements in away, that they validate against PUBLIC COMMON Schemas?”
Greetings Benjamin
Anyway, still the best SGML/XML/DTD Parser/Validator is James Clarks “nsgmls”:
http://www.jclark.com/sp/index.htm
posted at 12:31 pm on February 1, 2005 by Benjamin
5 A Support Issue
Support for XHTML and “at-the-browser” XML parsing is very limited right now, which is why in the battle of “HTML vs. XHTML,” HTML is the winner because it is more widely supported. I completely agree that XML is very powerful and flexible, but you should parse your XML and output it as HTML 4.01 strict until at-the-browser parsing is not so iffy. Otherwise, an excellent article at explaining something that is not very well-known.
posted at 02:19 pm on February 1, 2005 by Jonathan Fenocchi
6 Case sensitive css classes
After I added my
<!DOCTYPE html SYSTEM “dtd/xhtml1-custom.dtd” >
tag to the top of my document a curious oddity manifested itself. All my class attribute values became case sensitive. I suppose it’s my own fault for putting capitisation on my class name (coretable vs CoreTable) but it’s still a bit weird though imho.
posted at 05:19 pm on February 1, 2005 by Sam
7 Inline DTD declaration
If I ever wanted to use this tip, I’d really want to use the inline DTD stuff instead of creating a new page and referencing that. But of course the issue with ]> showing up in browsers is bad.
I haven’t actually tested this yet, but I would expect that serving your page with a MIME type of ‘text/xml+xhtml’ would fix this issue for at least Safari and Mozilla, since, IIRC, using that MIME type causes those browsers to use a real XML parser. Of course, the downside is if the page isn’t well-formed then it’s not displayed at all, but the upside is you can do whatever you want that’s legal in XML, including things like declaring new entities inline in the DOCTYPE and using them in the page (which might be handy).
posted at 07:03 pm on February 1, 2005 by Kevin Ballard
8 Downside?
Just to tickle Kevin, the fact that a bad-formed XML document is not displayed is not a downside but a plus. Each and every other programming language won’t let you compile/execute fautive code. Everything is simpler that way, there’s no guesswork involved.
Yes, at first it seems harder for the programmer, but in the end it makes everything easier because you don’t waste time battling different browser interpretations of a missing </div>.
posted at 10:35 pm on February 1, 2005 by Patrice Levesque
9 quirks and namespaces
How do custom DTDs affect doctype sniffing (for purposes of deciding between rendering in quirks or standard mode)? Do browsers sniff for any doctype or specific ones? I.e. will using custom DTDs make the rendering model behave differently?
Also, why can’t we use namespace switching instead? As long as IE (and other browsers) simply ignore the switching, and the validator is pacified by them, everyone is happy, right?
posted at 11:41 pm on February 1, 2005 by Ruy
10 .
Ah, that explains why I though I was going crazy in 2003 and could not figure out why the “]>” appeared. Thus I finally use a separate DTD Fragment file and used:
<![INCLUDE[
<!ENTITY % xhtmldtd
PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN”
“http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd” >
%xhtmldtd;]]>
However, you’re correct when served as “application/xhtml+xml” no appearance of “]>” on canvas.
Though still I am happy with the method I finally used 2003 as it was cleaner for multiple files.
posted at 02:08 am on February 2, 2005 by Robert Wellock
Discussion Closed
New comments are not being accepted, but you are welcome to explore what people said before we closed the door.
Got something to say?
Discuss this article. We reserve the right to delete flames, trolls, and wood nymphs.
Create a new account or sign in below if you’d like to leave a comment.
Subscribe to this article's comments: RSS (what’s this?)
1 Interesting Possibilities
For implementation of certain parts Web Forms 2.0 (http://www.whatwg.org/specs/)? Most of these attributes could be processed by javascript and servers instead of the UA.
Now we’re starting to see the true benefits of XML. But I wonder what are the benefits here for sites serving text/html? Technically its allowed for XHTML 1.0 and javascript should work the same, but all this effort really does is trick the validating programs—tag soup is tag soup is tag soup. Altering your DTD won’t make a difference one way or another unless browsers look at your page as XML, which only the most zen developers even dare think about.
posted at 09:59 am on February 1, 2005 by Ryan Cannon