The StructuredBlogging folks have run into validation issues when including foreign-namespaced XML in a <script> block in XHTML. Might dropping the DOCTYPE sidestep those?
Incidentally, due to the angle brackets in your title, Bloglines does silently drop the <!DOCTYPE> (Phil Ringnalda now includes markup in his titles as a matter of course, waiting for aggregator developers to do the right thing with Atom).
Danny, without the <!DOCTYPE, no parser is going to attempt DTD-based validation, so in that sense it would sidestep the issues. On the other hand, you won't find out if you've got <p>'s inside your <h3>'s either. For data entry, I'd probably build a RELAX NG grammar and validate with that. I certainly would want some sort of validation.
With respect to Bloglines, yeah, I noticed that too. Add it to the pile of rendering bugs in Bloglines, I guess. About once a week now, I'm irritated enough by their bugs to consider switching. But never (yet!) enough to overcome the inertia.
In addition to the broken rendering, I bet my RSS feed is busted as written because I refuse to double-escape the markup. That moves me one step closer to redirecting the RSS feeds to the equivalent Atom feeds and pulling the plug on the RSS.
Oh, the irony!
I read this post in Sage from Planet XML. It was titled "Drop the".
Micah Dubinko adds the post to his bookmarks, under the same title "Drop the", but the funny thing is if you view source there's still a hidden <!DOCTYPE> in the link.
Wouldn't it be nice if in 2006 at least Planet XML could get this stuff right?
Bart: they can’t, not if they consume RSS. Silent data loss. It’s impossible to fix because the spec is not unambiguous enough. They’d have to consume Atom to be able to stick a fork in this issue.
Norm: IMHO processing instructions are exactly the right tool for this scenario. They’re not at all aesthetically offensive; they’re just widely misused. But not here. (Which I am guessing is exactly what you’re thinking.)
If it's a fixed grammar over which you have no control, then a pre-processing expansion stage may be necessary but for xmlspec
I think the reason we all have so many messy date entities is that the header XML elements are not sufficiently structured and the thing to do is fix that and the update the main xmlspec stylesheet to match, rather than to switch the entity processing from dtd to a new PI based syntax.
For example if there were elements in xmlspec that allowed you to specify
draft.day = "05" , draft.month = "1" draft.year="2006", draft.class="NOTE" and draft.name="example"
Then the xmlspec stylesheet should be able to figure out for itself what the current-location should be (so this needn't be specified in the XML)
similarly having to specify the month in different places a "1" "01" and "January" is something that the stylesheet cold take care of, and if the date is only specified in one place in the XML file there is no need to make an entity for it.
For the general case of a DTD-replacement macro system I'm not sure that PI's are quite up to the job, unfortunately. Or more exactly a syntax which has the replacement text as PI content rather than between two PIs is not up to the job. Given that character references aren't recognised as such in a PIContent (and neither are element start tags) what does text="<x>a <x>" expand to, just the character string, or an x element with a space? I wasn't sure from your description. Either answer has some benefits and some potential confusions....
In case anyone is interested, I modified this script to work under XSLT 1.0 and EXSLT. Norm, thanks very much for the original idea and implementation.
After I modified your script, I thought it would be a good idea to have some public macros available for use. So I put together a set of macro equivalents of the common character entities.
Also, did you mean for that first <xsl:variable/> to be an <xsl:param/>, so that people can pass in a reference to a set of default macros? I modified my version to work that way.