Sorry Tim! :)
On 3/30/06, M. David Peterson <[EMAIL PROTECTED]> wrote:
> @href attribute *or other attribute or elements who's value CAN or MUST be a URI/IRI*On 3/30/06, M. David Peterson < [EMAIL PROTECTED]> wrote:I have to wonder why xml:base would apply to anything other than the hardline schema specific @href attribute values of the structured document in which the schema directly applys to. Extending this, a good portion of an Atom document is fairly rigid in regards to what is and is not allowed until you reach the content element. Within the content element can be basically anything as long as its either
- non-escaped plain text with a @type value set to text,
- escaped text,with a @type set to a valid 'text' mime-type
- enitity escaped with @type set to html,
- xhtml wrapped in a properly xhtml namespaced div with @type set to xhtml,
- base64 encoded with @type set to the proper media type, or
- its xml with @type set to a proper XML mime-type.
In each of these cases, the only one that shold have even a remote chance of the current value of the @xml:base in current context applying to is inline xml. But given the fact that those of us who are inlining xml (that isn't xhtml pulled from a referenced document) are doing so using a completely different namespace, schema, etc...
then the chances that the current @xml:base value in context even making it into the related xml before being replaced by another @xml:base value is not all that great. And if it does? Then its context document is going to be it's containing Atom file, in which xml:base would apply, but to what? It's in a different namespace, has a different schema that applies to it, which would then mean that the chances of the Atom savvy processor understanding that a particular element or attribute value is a URI, and should therefore apply the current @xml:base value in context to these values obviously is not something that fits within the confines of the Atom specication given the fact that theres no guarentee that a schema language it even partially understands is going to be applied to the contained content to act as a URI-guide for the now legally Blind as a BAtom processor. ;)
With all of this stated, if you're not all already sick of me, heres one last final point to help push you over the edge ;) :D
The escaped HTML content contained within the content element that David was originally concerned with is more than likely a copy of all or part of the elements and content contained inside the body tag of the external document referenced by an associated link element, and therefore no guarentee that the xml:base of the atom feed is going to be anywhere even close to accurate. Of course for the Atom feed to validate correctly, the link elements @rel value will need to be either 'alternate', 'via', 'related', or a spec conforming IRI, as 'enclosure', if inline, is base64 encoded, and 'self''? Well now that wouldn't apply correctly to a link/@rel who has a grandparent by the name of feed, now would it :)
So this all brings us down to the last possible scenario... The @src of the content element.
It would seem to me that if there is an @xml:base value currently in context, then as soon as it reaches the '>' character of the opening content element, it no longer has jurisdiction...
Kind of like a Canadian mounty has to call it quits once He/She reaches to CA/USA borderline...
Or something like that anway :)
Peace, Love, and all the Atomic Joy you can handle is wished upon all of you :)On 3/30/06, Sean Lyndersay < [EMAIL PROTECTED]> wrote:
This is unfortunate, because HTML itself only allows <base> elements in the header (one per page). So if anyone wants to build a client that displays more than one item at a time using a standard HTML renderer (and most client render HTML using someone else's renderer, not their own), they have to go groveling in HTML to do URL fixup (or use iframes).
In my own case (IE7) case, this isn't that big a deal because we have to grovel in HTML for many other reasons, but I suspect it'd be pain for other clients.
My own reading goes like this: Since xml:base is an XML concept, it should apply only to relative references in XML content (including XHTML). From the XML perspective, the HTML content is just a string, so the xml:base should not apply.
Sean
-----Original Message-----
From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] ] On Behalf Of Tim Bray
Sent: Thursday, March 23, 2006 10:49 AM
To: David Powell
Cc: Atom Syntax
Subject: Re: Does xml:base apply to type="html" content?
On Mar 23, 2006, at 10:03 AM, David Powell wrote:
>
>
> xml:base applies to type="xhtml" content, but I'm not sure whether it
> is supposed to apply to escaped type="html" content? I reckon that it
> does.
RFC4287, section 2:
Any element defined by this specification MAY have an xml:base
attribute [W3C.REC-xmlbase-20010627]. When xml:base is used in an
Atom Document, it serves the function described in section 5.1.1 of
[RFC3986], establishing the base URI (or IRI) for resolving any
relative references found within the effective scope of the xml:base
attribute.
Seems pretty clear to me. Yes, the base URI of that HTML is now
whatever xml:base said it was -Tim--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
--
<M:D/>
M. David Peterson
http://www.xsltblog.com/
