Subject: Re: xml:base and html rendering

From: David Powell <[email-masked]>
Date: Thu, 21 Apr 2005 11:39:13 +0100

Quoting Bill de hÓra <[email-masked]>:

> > I think we need to update the draft and stress that (X)HTML content is
> > not subject to xml:base processing.

I didn't read this carefully enough when I replied earlier, I didn't see that
Robert was suggesting that xml:base shouldn't apply to (X)HTML at all (which is
what I was suggesting too).

Don't forget that the URI of the Atom document also sets the base URI; xml:base
is just one way that the base URI is set.  A step further would be to say that
content has no defined base URI, so relative references must not be used.

> Why would we would mandate short-circuiting xml:base processing for
> XHTML via spec text, but default namespace processing via markup
> signals? Consistency would suggest some kind of wrapper/marker for xml:base.

I don't really understand what you mean by a wrapper/marker, can you give an
example?

--
Dave

---

From: Eric Scheid <[email-masked]>
Date: Thu, 21 Apr 2005 21:07:34 +1000

> I don't really understand what you mean by a wrapper/marker, can you give an

like this?

<content type="xhtml"><div xmlns="xhtml-ns"
xml:base="blah">...</div></content>

e.

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 21 Apr 2005 12:37:57 +0100

> I don't really understand what you mean by a wrapper/marker, can you give an

atom:content[@rel="freebase|nobase"] ?

Just kidding...

No, the thing is these two are similar problems structurally insofar as 
processing directives from the Atom layer are bleeding into the content. 
The way we're currently solving the namespace problem is via a xhtml:div 
tag in the format, plus spec text. The way Rob's suggesting we solve the 
xml:base directive is not via the format, just spec text. Also from one 
perspective, the latter case prefers a profiling of xml:base's scope 
whereas the former prefers to format defensively against namespace 
scope. Foolish inconsistencies notwithstanding, I would prefer we had a 
consistent approach here, since I'm not sure we've seen the last 
possible scoping issue.

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Thu, 21 Apr 2005 08:26:32 -0400

> processing directives from the Atom layer are bleeding into the content. 

No. xml:base doesn't mean anything in (x)html, ever, so there is no need 
for a structural measure. Additional spec text wouldn't be adding 
requirements, just spelling out what's implied by our references.

Robert Sayre

---

From: Anne van Kesteren <[email-masked]>
Date: Thu, 21 Apr 2005 14:33:34 +0200

Robert Sayre wrote:
>> No, the thing is these two are similar problems structurally insofar 
>> as processing directives from the Atom layer are bleeding into the 
>> content. 
> 

XHTML2 has xml:base and Mozilla for example supports xml:base in XHTML 
documents.

-- 
  Anne van Kesteren
  <http://annevankesteren.nl/>

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 21 Apr 2005 14:38:17 +0100

> requirements, just spelling out what's implied by our references.

Aside from what Anne said, I just scanned the XML Base spec and can't 
find anything scope wrt to child elements and attributes. In particular 
this (quoted previously here):

[[[
The deployment of XML Base is through normative reference by new 
specifications, for example XLink and the XML Infoset. Applications and 
specifications built upon these new technologies will natively support 
XML Base. The behavior of xml:base attributes in applications based on 
specifications that do not have direct or indirect normative reference 
to XML Base is undefined.
]]]

had nothing to say about scope. What is implied by our references 
appears to be it xml:base either evaluates to all the children under 
which it's declared or the behavior is undefined because the spec didn't 
define xml:base usage.

So I guess my question is - how is scoping xml:base to not apply within 
atom:content where type is xhtml not profiling XML Base?

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Thu, 21 Apr 2005 09:59:01 -0400

Bill de hÓra wrote:

> What is implied by our references 

If were using XHTML2, I'd agree with you. The XHTML1 family doesn't use 
xml:base. A vocabularly must identify which of its elements are subject 
to xml:base processing. For example, "XLink normatively references XML 
Base for interpretation  of relative URI references in xlink:href 
attribute".

I suppose the case could be made that we're defining our own little 
language here, so we are within our rights. Not a very interesting 
question, because xml:base seems to create problems for aggregated HTML 
displays. A huge bug, IMHO.

Robert Sayre

---

From: Norman Walsh <[email-masked]>
Date: Thu, 21 Apr 2005 11:19:05 -0400

/ Bill de hÓra <[email-masked]> was heard to say:
| Aside from what Anne said, I just scanned the XML Base spec and can't
| find anything scope wrt to child elements and attributes. In
| particular this (quoted previously here):
|
| [[[
| The deployment of XML Base is through normative reference by new
| specifications, for example XLink and the XML Infoset. Applications
| and specifications built upon these new technologies will natively
| support XML Base. The behavior of xml:base attributes in applications
| based on specifications that do not have direct or indirect normative
| reference to XML Base is undefined.
| ]]]
|
| had nothing to say about scope. What is implied by our references
| appears to be it xml:base either evaluates to all the children under
| which it's declared or the behavior is undefined because the spec
| didn't define xml:base usage.
|
| So I guess my question is - how is scoping xml:base to not apply
| within atom:content where type is xhtml not profiling XML Base?

That would seem really strange to me. The xml:base attribute on an
ancestor of atom:content changes the [base uri] property in the
infoset. Down inside atom:content, suppose you find an html:div; what
is its base URI? To answer that, you look for the applicable [base
uri] property. I don't know any other way to do it.

I suppose we could say that the base URI for atom:content is undefined
but that seems odd too. It strikes me that that might be tricky too.

Do we say that elements put in atom:content SHOULD use absolute URIs.
We probably, uhm, should :-)

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | It is good to have an end to journey
http://nwalsh.com/            | toward; but it is the journey that
                              | matters, in the end.--Ursula K. LeGuin

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 21 Apr 2005 16:45:32 +0100

> uri] property. I don't know any other way to do it.

Sure. My point (which still stands afaict) is that this is a structural 
matter, to do with bleed from the container in the content and that 
we've solved it with a different approach altogether for namespaces than 
what's being suggested for xml:base. I guess I'm trying to get the WG to 
think about at this an 'document architecture' level rather than 
patching issues on a per case basis as we find them. But I guess people 
can judge for themselves whether the fact that Atom might corrupt 
carried content is an issue.

> We probably, uhm, should :-)

I agree, but you don't sound sure :-)

cheers
Bill

---

From: Robert Sayre <[email-masked]>
Date: Thu, 21 Apr 2005 11:52:55 -0400

Bill de hÓra wrote:
> I guess I'm trying to get the WG to 

What should we do about the 'document architecture'? Suggestions?

Robert Sayre

---

From: Henri Sivonen <[email-masked]>
Date: Thu, 21 Apr 2005 18:49:13 +0300

On Apr 21, 2005, at 15:26, Robert Sayre wrote:

> No. xml:base doesn't mean anything in (x)html, ever, so there is no 
> need for a structural measure.

In practice, anything that end up in the xml: namespace is part of the 
infrastructure and generic underpinnings won't turn them off based on 
higher-level specs.

Are you suggesting Mozilla is wrong in supporting xml:base in a generic 
way (including in XHTML)?

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Robert Sayre <[email-masked]>
Date: Thu, 21 Apr 2005 12:31:45 -0400

> way (including in XHTML)?

I don't care about Mozilla (right now). We have xml:base, and we know 
it's not going to work quite right, all of the time. Either we warn 
people, or we don't. This may signal a deeper problem with xml:base, or 
XML itself.

If Atom Processors are to take the Feedparser approach, they shouldn't 
be used as endpoints for the protocol, because you don't want the server 
changing your nice, short relative references into full URIs.

I'm not sure any spec language will help. Maybe 'use absolute URIs for 
maximum data integrity', but I suppose that is always true.

Robert Sayre

---

From: Bill de hÓra <[email-masked]>
Date: Thu, 21 Apr 2005 17:55:19 +0100

Robert Sayre wrote:
> Bill de hÓra wrote:
> 
>> I guess I'm trying to get the WG to think about at this an 'document 
>> architecture' level rather than patching issues on a per case basis as 
>> we find them. But I guess people can judge for themselves whether the 
>> fact that Atom might corrupt carried content is an issue.
> 
> 

I'm not sure anyone here agrees there's a 'document architecture' issue 
to begin with :\  That said, consistency of approach would be good, or 
at least articulating why consistency isn't needed in these cases would 
be good. Being explicit about profiling would be good if that's what 
we're going to do. Being sure that adding features like xml:base and 
xhtml:div are not more trouble than they're worth is good. Test cases 
would be good (thank you for yours). Here's what we don't do - fob it 
off to the Fabled Implementors Guide, or find out a week after we ship 
we made more Terrible Mistakes than we needed to.

cheers
Bill

---

From: "A. Pagaltzis" <[email-masked]>
Date: Thu, 21 Apr 2005 19:27:48 +0200

* Bill de hÓra <[email-masked]> [2005-04-21 17:55]:
> My point (which still stands afaict) is that this is a
> structural matter, to do with bleed from the container in the
> content and that we've solved it with a different approach
> altogether for namespaces than what's being suggested for
> xml:base. I guess I'm trying to get the WG to think about at
> this an 'document architecture' level rather than patching
> issues on a per case basis as we find them.

On the structural level these all sound like issues of XML-in-XML
in general, not Atom in specific. I don’t mean in the sense of
how to do that with XML at all; I mean in the sense of how XML
vocabularies should be designed so they can be integrated
cleanly. It looks like this is largely unexplored area without
any best practices to speak of so far.

This is merely an observation. I’m not sure what it means for
Atom.

Regards,
-- 
Aristotle

---

From: Robert Sayre <[email-masked]>
Date: Thu, 21 Apr 2005 14:05:55 -0400

Bill de hÓra wrote:

> Being explicit about profiling would be good if that's what 
> xhtml:div are not more trouble than they're worth is good. 

On xml:base, I don't think we actually have a problem with the document 
architecture. If you're processing an Atom entry you get an (X)HTML 
fragment and a base URI. The information is there, it's just that it may 
be difficult to *leave* the Atom format and repurpose it. So, is there 
something more useful we could provide? Looks like the generic 
relative/absolute trade-off.

If you've got an embedded HTML library, you can probably deal with it 
just fine.

If you have a web interface, you get the nasty problem of combining the 
content into one HTML format and base URI. It might be possible to deal 
with baseURIs using event bubbling or other JS hacks, but that won't 
help spiders and such.

The Feedparser approach is fine, but it's definitely not the definition 
of a 'competant' Atom Processor, energetic as it is. Roundtripping might 
be more important that HTML munging.

David has previously mentioned xml:base interactions with atom:source. 
Any other issues?

I guess we could also use a quick survey of xml:base support in parsers, 
xslt implementations, etc. if we don't already have one. xml:base was 
supposed to be in XSLT 1.1, and Saxon supports it right now.

Robert Sayre

---

From: Norman Walsh <[email-masked]>
Date: Thu, 21 Apr 2005 16:04:47 -0400

/ Robert Sayre <[email-masked]> was heard to say:
| I guess we could also use a quick survey of xml:base support in
| parsers, xslt implementations, etc. if we don't already have one.
| xml:base was supposed to be in XSLT 1.1, and Saxon supports it right
| now.

Support for xml:base is part of the XPath 2 family of specs.

                                        Be seeing you,
                                          norm

-- 
Norman Walsh <[email-masked]> | Men are more like the times they live
http://nwalsh.com/            | in than they are like their
                              | fathers.--Ali Ibn-abi-talib

---

From: David Powell <[email-masked]>
Date: Fri, 22 Apr 2005 08:59:50 +0100

Thursday, April 21, 2005, 7:05:55 PM, you wrote:

> xslt implementations, etc. if we don't already have one.

> xml:base was supposed to be in XSLT 1.1, and Saxon supports it right
> now.

Does XSLT 1.1 support xml:base in the source document? My reading of
it was that it just supported it in the stylesheet itself.

-- 
Dave

---

From: Robert Sayre <[email-masked]>
Date: Fri, 22 Apr 2005 09:30:16 -0400

> it was that it just supported it in the stylesheet itself.

Perhaps you're right. Looking closer, Saxon seems to support XPath2 
these days (Saxon 8.4B) including the function fn:resolve-uri. XSLT1.1 
was cancelled anyway, I think.

Robert Sayre

---

From: Graham <[email-masked]>
Date: Fri, 22 Apr 2005 15:40:06 +0100

On 21 Apr 2005, at 7:05 pm, Robert Sayre wrote:

> Bill de hÓra wrote:
>
>> Being explicit about profiling would be good if that's what we're 
>> going to do. Being sure that adding features like xml:base and 
> On xml:base, I don't think we actually have a problem with the 
> document architecture. If you're processing an Atom entry you get an 
> (X)HTML fragment and a base URI. The information is there, it's just 
> that it may be difficult to *leave* the Atom format and repurpose it. 
> So, is there something more useful we could provide? Looks like the 
> generic relative/absolute trade-off.

Completely agree. Any content that allows relative links within itself 
would have to have some concept of an external base URI, whether or not 
the content format supports xml:base itself internally. An Atom 
processor just has to hand over the chunk of data and the current state 
of xml:base.

I think the appropriate way to put multiple entries onto one HTML page 
would is for the app doing to rewrite the URIs inside it to be 
absolute. Requiring URIs in the content to be absolute to begin with is 
too expensive, and probably completely unenforceable.

Graham

---

From: "Roger B." <[email-masked]>
Date: Fri, 22 Apr 2005 15:38:38 -0500

> Requiring URIs in the content to be absolute to begin with is

Graham: I suppose that, if nothing else, it's a self-correcting
problem. When all those hybrid RSS/Atom parsers out there display
broken images or links, most publishers will get a clue and make sure
they're putting absolute URIs in their feeds.

And if they don't mind broken images and links, well, I guess it
wasn't much of a problem in the first place.

--
Roger Benningfield
http://admin.support.journurl.com/

---

From: Sjoerd Visscher <[email-masked]>
Date: Sat, 23 Apr 2005 23:21:13 +0200

> wasn't much of a problem in the first place.

You are right. RSS has this problem already, and it isn't really that 
much of a problem, just a slight annoyance. As aggregators I've only 
ever used Radio Userland and Bloglines, and they both don't resolve 
relative URIs correctly.

But there still are plenty of RSS feeds with relative URIs in them. The 
workaround as user is to simply follow the link to the item first, and 
then click the link there on the original page.

The only thing that changes with xml:base support in Atom is that 
aggregators who *do* resolve relative URIs, now have more chance to get 
the originally intended base URI.

And a side effect is apparently that aggregator writers are alerted to 
the relative URI problem, instead of just staying ignorant about it.

-- 
Sjoerd Visscher
http://w3future.com/weblog/

---

From: Thomas Broyer <[email-masked]>
Date: Sun, 24 Apr 2005 15:39:17 +0200

> the originally intended base URI.

But the Atom spec says:
[
    Any element defined by this specification MAY have an xml:base
    attribute.  XML Base [W3C.REC-xmlbase-20010627] processing MUST be
    applied to any relative reference [RFC3987] present in an Atom
    Document.  This includes such elements and attributes as specified by
    Atom itself, as well as those specified by extensions to Atom.
]

*All* aggregators MUST resolve any relative URI reference.

We could narrow the XML Base "MUST" scope only to "the elements and 
attributes as specified by Atom itself, as well as those specified by 
extensions to Atom" and use a MAY or SHOULD for references found in HTML 
and XHTML (in text constructs and atom:content) as well as inline 
foreign content (in atom:content).

-- 
Thomas Broyer

---

From: Sjoerd Visscher <[email-masked]>
Date: Sun, 24 Apr 2005 17:26:55 +0200

Thomas Broyer wrote:
>> aggregators who *do* resolve relative URIs, now have more chance to 
>> get the originally intended base URI.
> 

All aggregators must resolve relative URI references in RSS too to work 
properly.

So with Atom the aggregators are broken according to spec, with RSS the 
aggregators are broken according to practice. Who cares about that 
difference?

---

From: Tim Bray <[email-masked]>
Date: Sun, 24 Apr 2005 08:29:16 -0700

On Apr 24, 2005, at 6:39 AM, Thomas Broyer wrote:

> extensions to Atom" and use a MAY or SHOULD for references found in 
> HTML and XHTML (in text constructs and atom:content) as well as inline 

I don't think there should be any ambiguity here.  The language should 
be changed to say

"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 for 
resolving any relative URI references found within the effective scope 
of the xml:base attribute."

This makes it clear that if there is an xml:base whose scope includes 
<atom:content>, then yes indeed, the intent is to establish a base URI 
for the content.  One of my main gripes about RSS is that it has no 
rules, so you effectively can't use relative URIs, thus ruling out a 
common good Web practice.  I see clarity on this front as one of the 
practical advantages offered by Atom.  -Tim