On 1/1/07, Geoffrey Sneddon <[EMAIL PROTECTED]> wrote:> Why, may I
ask, MUST (under the RFC 2119 definition) HTML
content be a fragment ("HTML markup within SHOULD be such
that it could validly appear directly within an HTML <DIV>
element, after unescaping." - note the word SHOULD, not
MUST, implying that you can have a full HTML document within)?
What would you do if you wanted to display a feed of 10 entries in
"newspaper" style (i.e. all entries in a single HTML page) yet each of the
entries had a different BASE defined? It wouldn't do you much good to move
all the base elements to the HEAD of the DOM tree -- you'd just end up with
a mess. If you want a local base, then use xml:base. That's what it is for.
The same problem exists for other page-global stuff. For instance, XHTML
modularization is useless if you're creating Atom entries since that stuff
relies on elements in HEAD but, an Atom entry ain't got no head....
Remember as well that not all of the entries in a feed document need be
created by the same person. For instance, with aggregated or synthetic
feeds, you end up with entries written by many different authors who have no
chance of negotiating how they will divide the global resources that might
be used to display their entries. Because some entries may be signed, you
can't simply say something like "just rewrite the entries" -- that would
break the signatures.
It is good that Atom entries should be fragments. That increases to a great
degree the variety of environments in which Atom entries are useful. If you
feel constrained by this, I would suggest that you push on those who define
HTML and get them to provide mechanisms for allowing fragment-local
expression of things that at this time can only be expressed as page-global.
(Yes, I realize this will take some time.)
bob wyman
