On 20/7/05 3:08 PM, "James Cerra" <[EMAIL PROTECTED]> wrote:
> Section 3.2.2:
> --
>> The "atom:uri" element's content conveys an IRI associated with the person.
>> Person constructs MAY contain an atom:uri element, but MUST NOT contain more
>> than one. The content of atom:uri in a
I took some notes while reading the specification. Not all of them are good
notes, and I was cranky while writing them. Still, they do have some issues
or slightly vague points about the spec from my view point.
Section 1.2:
> http://www.w3.org/2005/Atom
I guess consistancy is n
* Graham <[EMAIL PROTECTED]> [2005-07-20 01:20]:
> While I agree this interpretation is potentially correct, it
> moves us pretty far away from the idea of a self-contained
> document with a singular embedded base URI, which is all that
> RFC2396 ever discusses.
That is pretty much what I said;
FYI... I've submitted an I-D for my Feed Index extension. Not sure when
it will be published. I uploaded a copy here:
http://www.snellspace.com/public/draft-snell-atompub-feed-index-00.txt
- James
On 19 Jul 2005, at 9:28 am, A. Pagaltzis wrote:
Now, xml:base appears to try to address the situation where an
aggregate document may contain fragments from many sources, and
each of which thus has its own base URI.
While I agree this interpretation is potentially correct, it moves us
prett
* Sjoerd Visscher <[EMAIL PROTECTED]> [2005-07-19 12:35]:
> I don't find applying same-document reference behaviour to
> fragments of an aggregate document non-sensical. If I XInclude
> a piece of XHTML that has same-document references in it, I
> still want them to be same-document references, an
Reluctantly, I must admit that I can't find anything in RFC 3986 or the
xml:base spec to convince me that the "same document reference" rule
doesn't cause the problems for Tim's feed that have been asserted. The
existence of the text regarding same document references, and the fact
that that
On Jul 19, 2005, at 3:23 AM, Sjoerd Visscher wrote:
A. Pagaltzis wrote:
It makes me wonder whether the person who wrote the example was
unaware of the consequences of the same-document reference
specifications in the URI RFC. Surely, the xml:base WG must have
noticed this issue and dis
If anyone comes to a definitive conclusion on this,
would they post to the list, or a website please.
TIA
--
Regards,
Dave Pawson
XSLT + Docbook FAQ
http://www.dpawson.co.uk
On Tuesday, July 19, 2005, at 12:29 PM, Antone Roundy wrote:
On Monday, July 18, 2005, at 01:59 AM, Stefan Eissing wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful
feed. As an alternative one could drop fh:stateful and define that an
empty fh:prev (refering to itself)
On Monday, July 18, 2005, at 01:59 AM, Stefan Eissing wrote:
Ch 3. fh:stateful seems to be only needed for a newborn stateful feed.
As an alternative one could drop fh:stateful and define that an empty
fh:prev (refering to itself) is the last document in a stateful feed.
That would eliminate
A. Pagaltzis wrote:
It makes me wonder whether the person who wrote the example was
unaware of the consequences of the same-document reference
specifications in the URI RFC. Surely, the xml:base WG must have
noticed this issue and discussed it?
I wonder how many people are aware of it. I won
On 19 Jul 2005, at 01:52, A. Pagaltzis wrote:
* Mark Nottingham <[EMAIL PROTECTED]> [2005-07-18 23:30]:
This is one of the unanswered questions that I left out of
scope. The consumer can examine the previous archive's URI and
decide as to whether it's seen it or not before, and therefore
a
On 18 Jul 2005, at 23:21, Mark Nottingham wrote:
On 18/07/2005, at 2:17 PM, Stefan Eissing wrote:
On a more semantic issue:
The described sync algorithm will work. In most scenarios the
abort condition (e.g. all items on a historical feed are known)
will also do the job. However this sti
Am 18.07.2005 um 23:21 schrieb Mark Nottingham:
On 18/07/2005, at 2:17 PM, Stefan Eissing wrote:
On a more semantic issue:
The described sync algorithm will work. In most scenarios the abort
condition (e.g. all items on a historical feed are known) will also
do the job. However this still
* David Powell <[EMAIL PROTECTED]> [2005-07-19 08:25]:
> Why does xml:base allow for relative base URIs and stacking
> then? If xml:base can only describe the actual source URI of
> the document, then these features don't make sense.
Indeed, they don’t.
> The example in the xml:base spec [1] use
16 matches
Mail list logo
