On Apr 24, 2005, at 6:39 AM, Thomas Broyer wrote:
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 a
Thomas Broyer wrote:
Sjoerd Visscher wrote:
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.
*All* aggregators MUST resolve any relative URI reference.
All aggregators must r
Sjoerd Visscher wrote:
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.
But the Atom spec says:
[
Any element defined by this specification MAY have an xml:base
attribu
Roger B. wrote:
Requiring URIs in the content to be absolute to begin with is
too expensive, and probably completely unenforceable.
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 publish
David Powell wrote:
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.
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 cancel
Thursday, April 21, 2005, 7:05:55 PM, you wrote:
> 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.
Does XSLT 1.1 support xml:base in
/ Robert Sayre <[EMAIL PROTECTED]> 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 t
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
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. I
* Bill de hÃra <[EMAIL PROTECTED]> [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
>
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 i
Henri Sivonen wrote:
Are you suggesting Mozilla is wrong in supporting xml:base in a generic
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
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-le
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.
What sh
Norman Walsh wrote:
| 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 i
/ Bill de hÃra <[EMAIL PROTECTED]> 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
Bill de hÓra wrote:
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
ato
Robert Sayre wrote:
Bill de hÓra wrote:
No, the thing is these two are similar problems structurally insofar
as 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
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.
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 b
Bill de hÓra wrote:
No, the thing is these two are similar problems structurally insofar as
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
David Powell wrote:
Quoting Bill de hÓra <[EMAIL PROTECTED]>:
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
On 21/4/05 8:39 PM, "David Powell" <[EMAIL PROTECTED]> wrote:
>> 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 rea
Quoting Bill de hÓra <[EMAIL PROTECTED]>:
> > 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)HTM
Robert Sayre wrote:
David Powell wrote:
I recently tried to render a bunch of Atom entries as an HTML page and
I hit a problem. I think it is probably worth mentioning now in case
any implementors hadn't noticed it:
Atom supports xml:base anywhere in the document, so different entries
can have diff
Thursday, April 21, 2005, 12:32:00 AM, Robert Sayre wrote:
> David Powell wrote:
>>
>> I recently tried to render a bunch of Atom entries as an HTML page and
>> I hit a problem. I think it is probably worth mentioning now in case
>> any implementors hadn't noticed it:
>>
>> Atom supports xml:b
On 4/20/05, David Powell <[EMAIL PROTECTED]> wrote:
> Atom supports xml:base anywhere in the document, so different entries
> can have different base-URIs. HTML, however, doesn't support xml:base.
> This makes it difficult to display multiple entries on a HTML page.
Depending on your need for cor
David Powell wrote:
I recently tried to render a bunch of Atom entries as an HTML page and
I hit a problem. I think it is probably worth mentioning now in case
any implementors hadn't noticed it:
Atom supports xml:base anywhere in the document, so different entries
can have different base-URIs. HTM
I recently tried to render a bunch of Atom entries as an HTML page and
I hit a problem. I think it is probably worth mentioning now in case
any implementors hadn't noticed it:
Atom supports xml:base anywhere in the document, so different entries
can have different base-URIs. HTML, however, doesn
27 matches
Mail list logo
