/ 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
Phil Ringnalda wrote:
Robert Sayre wrote:
What would be necessary to get this feed to render on one HTML page,
ala Bloglines?
http://www.franklinmint.fm/2005/04/21/xmlbase.atom
Running it through a competant Atom processor?
http://feedparser.org/docs/resolving-relative-links.html
That's cool! It
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
Robert Sayre wrote:
What would be necessary to get this feed to render on one HTML page, ala
Bloglines?
http://www.franklinmint.fm/2005/04/21/xmlbase.atom
Running it through a competant Atom processor?
http://feedparser.org/docs/resolving-relative-links.html
Phil Ringnalda
/ 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
What would be necessary to get this feed to render on one HTML page, ala
Bloglines?
http://www.franklinmint.fm/2005/04/21/xmlbase.atom
Robert Sayre
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
21 matches
Mail list logo
