On 31/3/06 3:08 PM, "Antone Roundy" <[EMAIL PROTECTED]> wrote:
>> 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 doc
I speaking in terms of mashups... If a feed comes from one source, then I would agree... but mashups from both a syndication as well as an application standpoint are become the primary focus of EVERY major vendor. Its in this scenario that I see the problem of assuming the xml:base in current con
Yeah, agreed... In fact, I think at this stage of the game my inexperience in understanding all that must be considered during the development of a standard as far reaching as Atom both is and, even more so, will be is beginning to show through. None-the-less, this is an area I want to learn as mu
Yeah, I 100% agree with you on ALL of this... The break down was more to showcase "here's the best case scenario thats even remotely possible" but we all know that remotely possible and real world reliable are near polar opposites...
Actually, I think what you have layed out here has quite a bit o
Antone Roundy wrote:
>[snip]
> 2) If you're consuming Atom and you encounter a relative URI, how should
> you choose the appropriate base URI with which to resolve it?
>
> I think there are only three remotely possible answers to #2: xml:base
> (including the URI from which the feed was retriev
Sean Lyndersay wrote:
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.
Looking at the results of the Atom XmlBaseConformanceTests [1] mosts of the
clients tested seemed capable of hand
On Mar 30, 2006, at 10:00 PM, M. David Peterson wrote:
Then it should be a best practice that if they invoke this, the
xml:base value should be set upon the "element containing the
text", in this case, the content element. Obviously you can't
simply assume that the current xml:base in cont
I would agree that, as a best practice, the xml:base should appear on
the content element, but implementations need to be prepared to use
whatever the in-scope URI is (e.g. if no xml:base is specified, relative
refs in the content will be relative to Content-Location or the feeds
Request URI). In
On Mar 30, 2006, at 8:34 PM, M. David Peterson wrote:
...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 wra
Then it should be a best practice that if they invoke this, the xml:base value should be set upon the "element containing the text", in this case, the content element. Obviously you can't simply assume that the current xml:base in context has any direct relation, and therefore value to the current
In retrospect, it likely would have been a good idea for us to have
covered this in the Atom spec. The definition of xml:base does include
a statement that "[t]he base URI for a URI reference appearing in text
content is the base URI of the element containing the text." That would
include URI re
Oopps > Canadian *M*ount*ie*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
> @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 t
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 y
* Sean Lyndersay <[EMAIL PROTECTED]> [2006-03-31 04:00]:
>This is unfortunate, because HTML itself only allows
>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 usin
This is unfortunate, because HTML itself only allows 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 g
16 matches
Mail list logo
