[EMAIL PROTECTED] schrieb:
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
...
Hmmm, didn't we have agreement to change 'application/atomserv+xml' to
'application/atomsvc+xml'?
Best regards, Julian
James M Snell schrieb:
Quite frankly it doesn't matter what we call anything right now. The
server gets to determine what pieces of data it's willing to handle.
Period. If you want anything more than that, use webdav.
...
Again: WebDAV doesn't redefine PUT, so the situation is exactly the
Joe Gregorio schrieb:
...
This is the documented consensus of the WG. The next draft will have
verbage that makes this position clearer. If some implementations
find that too loose and want octet-for-octet storage they can use
always WebDAV.
[1]
James M Snell schrieb:
...
Now, to the WG as a whole: I really don't have any agenda for the
autodiscovery stuff other than to help foster it along. If y'all think
there is a need for a I-D defining autodiscovery for Atom and APP, I've
got a few spare cycles to help with the editing. If y'all
Well.
Could the IESG then please answer the following simple question...?
If HTTP/1.1 (as defined in RFC2616) would be submitted today for
publication as Proposed Standard, would it be accepted?
If no, shouldn't the IESG revoke the current status of Draft Standard,
and declare it as
Mark Nottingham schrieb:
I've only had positive comments about -07 so far, so I've recommended it
for publication as a Proposed Standard to the IESG.
As part of that process, I'm issuing an informal, pseudo-WG Last Call on
the document to capture any remaining feedback. In particular,
*
Paul Hoffman schrieb:
Dang, where'd that rule come from?
Probably RFC 2026, but if not there, it is certainly in the folklore of
How Things Are Done.
...
I thought this is possible if interop is demonstrated...
...
Best regards, Julian
Paul Hoffman schrieb:
At 3:01 AM -0400 10/2/06, Robert Sayre wrote:
I think we should move the format to Draft Standard by clearing up any
errata and adding two attributes: 'dir' and 'unicode-bidi', as defined
in XHTML.
We can't both add features and move to Draft Standard at the same
Robert Sayre schrieb:
...
Thanks for the clarification. You may have missed another question I
recently asked, so I'll repeat it here. I am concerned that purl.org
lists the document author as the owner of the namespace URI, and I
wonder how the IESG came to the conclusion that the namespace is
Sylvain Hellegouarch schrieb:
...
Just a thought like that but wouldn't it make sense for RFC 4287 to have
specified that every standardised extension should follow the same
namespace as RFC 4287?
For instance RFC 4287 uses http://www.w3.org/2005/Atom
Extensions should then be something like:
Thomas Broyer schrieb:
If I read RFC2616 correctly, nothing prevents the latest entries
only and full representations (or any representation of the same
resource) to share the same entity-tag, i.e. nothing prevents a server
to assign an entity-tag to a resource rather than its representations.
Elliotte Harold schrieb:
James M Snell wrote:
That's not quite accurate. Two entries with the same atom:id may appear
within the same atom:feed only if they have different atom:updated
elements. The spec is silent on whether or not two entries existing in
*separate documents* may have
I'm with Robert here.
To clarify what happened with the WebDAV specs he mentioned...:
- WebDAV Property Datatypes (RFC4316) hasn't been on the WG's agenda,
and currently is implemented only by two vendors. Thus, experimental
seems to be absolutely the right category.
- WebDAV Redirect
Martin Duerst wrote:
At 02:08 06/03/20, Elliotte Harold wrote:
I would recommend against using xsd:anyURI for IRIs. A URI is much
more restrictive than an IRI, and one of the easiest things for a schema
validator to check about an xsd:anyURI is that it only contains
URI-legal ASCII
Hi,
in the meantime Mark N. sent me the XML version of the submitted draft
(thanks!), which I have updated with the AUTH48 changes in RFC4287 (I
also changed it to be self-contained).
XML and HTML versions are now available from
http://greenbytes.de/tech/webdav/#rfc4287. Note that the XML
Hi,
the IETF WebDAV working group finally has produced a draft for the
revision of RFC2518 that we feel can be last-called in the working group
-- see Cullen's announcement below.
At this point it would be great to get feedback from people who
currently do not follow the WebDAV working
Hi,
is anybody aware of ongoing activities to produce XML/HTML versions of
RFC4287 based on the xml2rfc (rfc2629) XML format?
I'm fully aware that there currently probably is no XML version of the
spec that matches RFC4287, as the AUTH48 changes done by the RFC Editor
have been applied to
James M Snell wrote:
FYI: Thanks to Robert Sayre for pointing it out, but when y'all get a
chance, take a look at the internals of the new Google Reader app
(http://reader.google.com). It's using AJAX and Atom 1.0 feeds to serve
up the data into the browser interface. The interface
In
http://feedvalidator.org/check.cgi?url=http%3A%2F%2Fgreenbytes.de%2Ftech%2Fwebdav%2Fwebdav-ietf.atom,
why is the validator complaining about atom:updated elements to be the
same...? After all, both entries have different atom:id elements...
Confused,
Julian
James Holderness wrote:
If you read the help on that error message you'll see it's quoting
directly from section 3.3 of the Atom spec:
Date values SHOULD be as accurate as possible. For example, it would be
generally inappropriate for a publishing system to apply the same
timestamp to
Dave Pawson wrote:
On Thu, 2005-08-04 at 09:31 -0700, Tim Bray wrote:
I'm getting increasingly grumpy and just fail is looking better and
better.
So for now, I'm -1 on an weakening or removing The element's content
MUST be an IRI or analogous text in any other section. I'll stop
Graham wrote:
On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote:
The design intent of character-by-character cmp as I understood was for
the URI contained by the element. I think confusing the element content
with the URI is a spec bug.
From atompub-format-10, 4.2.6: Its content MUST be
Bill de hÓra wrote:
Julian Reschke wrote:
Graham wrote:
On 2 Aug 2005, at 10:07 am, Bill de hÓra wrote:
The design intent of character-by-character cmp as I understood was for
the URI contained by the element. I think confusing the element content
with the URI is a spec bug.
From
James Cerra wrote:
Ian Davis wrote:
Graham wrote:
That to me is demonstrates a very clear intention of the working group
that the content must be exactly equal to the IRI. Changing this to
allow whitespace would represent a major technical change to the
format. I will figuratively lie down
Sam Ruby wrote:
...
Why would they be legal with the RNG grammar
From http://www.w3.org/TR/xmlschema-2/#dt-whiteSpace:
For all ·atomic· datatypes other than string (and types ·derived· by
·restriction· from it) the value of whiteSpace is collapse and
cannot be changed by
Thomas Broyer wrote:
...
* when using the Atom Publishing Protocol's POST or PUT, it might be
worth defining an error document type to tell the client why its
document has been refused (e.g. POSTing an Atom Entry with a
base64-encoded MSWord content and the server only accepts
A. Pagaltzis wrote:
* James M Snell [EMAIL PROTECTED] [2005-07-26 01:00]:
part of the issue was what happens if the http response is 200
but the payload is trying to communicate that an error
occurred.
Nothing happens. 200 means no error occured. Returning 200 when
an error did occur is
Danny Ayers wrote:
If I could distract folks from the champagne and crudities for a moment:
First - I just received a rewrite of the spec draft in nicely-styled
XHTML 1.0, from someone (who wishes to remain anonymous) who refers to
the IETF docs as so 1989 -
Thomas Broyer wrote:
It is not, not at all.
To everyone here: please, comment on PaceOptionalXhtmlDiv, either +1 or
-1, but at least argument. See also further explanation and technical
arguments in Consensus call on last raft of issues [1]
...
For the record: I am +1 on
Eric Scheid wrote:
On 20/5/05 2:10 PM, Antone Roundy [EMAIL PROTECTED] wrote:
If we do allow multiple authors, we might want to put a warning in that
consuming applications MAY ignore some of them if more than one is
supplied. As long as we do that, and perhaps even if not, I'd be in
favor of
Tim Bray wrote:
On May 16, 2005, at 10:44 AM, Robert Sayre wrote:
I am not looking for a repeat of that discussion. Atom 1.0 Processors
cannot distinguish between markup added later on by the IETF and
markup added by a third party, so the processing rules must remain as
they are. That doesn't mean
Paul Hoffman wrote:
Thus spake RFC 2119:
3. SHOULD This word, or the adjective RECOMMENDED, mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different
Sam Ruby wrote:
...
The W3C could have made idempotency a MUST, which effectively would have
prevented useful things like hit counters.
...
Not true. Quoting RFC2616:
In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an
Bill de hÓra wrote:
...
{{{
o atom:feed elements MUST contain either and cannot contain both
- one or more atom:link elements with a relation of alternate.
- one and only one atom:link element with a relation of
no-alternate.
}}}
...
link rel=no-alternate /
...
Is this meant to
Bill de hÓra wrote:
...
Currently you MUST provide an alternate feed link. People are saying
they don't always have one to provide, which encourages garbage out.
That satisfying a spec constraint for its own sake. This addition allows
someone to say there is no alternate for this link. It's
Graham wrote:
On 6 May 2005, at 3:50 am, Sam Ruby wrote:
FYI: we have an instance proof of this requiring an existing tool to
do additional work:
http://www.imc.org/atom-syntax/mail-archive/msg13983.html
Tools will have to be updated to work with Atom? Scandalous.
+1 to the Pace
+1 as well.
Brett Lindsley wrote:
Andy, I recall bringing up the same issue with respect to portable
devices. My angle
was that firing up the transmitter, making a network connection and
connecting to
the server is still an expensive operation in time and power (for a
portable
device) - even if the server
Andy Henderson wrote:
Isn't this what the HTTP Expires header is for
(http://greenbytes.de/tech/webdav/rfc2616.html#header.expires)?
I don't think this helps a lot with my original issue because in many cases
a feed's updater will either not know when they will next update the feed,
or will be
Antone Roundy wrote:
On Wednesday, May 4, 2005, at 12:59 PM, fantasai wrote:
Again, my friend's blog feed is not an Atom version of /my/ web page;
linking to it as alternate would be wrong.
To me, this raises a red flag, suggesting that using an autodiscovery
link from your web page to your
Tim Bray wrote:
Mark Pilgrim agreed to turn his Atom autodiscovery draft into a WG
draft, and has done so, see:
http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.txt
http://diveintomark.org/rfc/draft-ietf-atompub-autodiscovery-01.html
For the record...:
+1 on not requiring wrapper elements
+1 on properly distinguishing between block-level and in-line
+1 on using the same recommendations for type=html as well
Best regards, Julian
Robert Sayre wrote:
Julian Reschke wrote:
Update -06: I'm still confused by the text. For instance:
- is it intentional that 4.1.3.3 says ``If the value of type ends
with +xml or /xml'', while 4.1.3.2 used ``If the value of type
begins with text/ or ends with +xml''?
Yes. In 4.1.3.3, you're
Quoting from Andrew Newton's questions relayed by Scott:
http://www.imc.org/atom-syntax/mail-archive/msg14048.html
From: Andrew Newton [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 05, 2005 6:25 PM
To: Scott Hollenbeck
Cc: [EMAIL PROTECTED]
Subject: Re: [xml-dir] FW:
Hi,
Firefox ironically displays a Live Bookmark icon for
http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html :-)
This is caused by LINK tags such as
link rel=Chapter title=2 Atom Documents href=#rfc.section.2
...whenever a title contains the string Atom, it is mis-detected as a
Hi,
I just updated my issues list based on the current draft (that is, I
didn't yet have time to scan for potential new issues). Most of the
issues are editorial, but two of them IMHO really need to be addressed
before the draft can be submitted (05-C05 and 05-E12).
Also, the embedded RNC
Antone Roundy wrote:
...
Proposal
In section 4.1.1 of atompub-format-06, change this:
* atom:feed elements MUST contain at least one atom:link element
with a relation of alternate.
To this:
* atom:feed elements SHOULD contain at least one atom:link element
with a relation of alternate.
Bill de hÓra wrote:
...
ultraliberal/+halfassedwebdav
...
I guess I need you to explain that joke.
Julian (confused)
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
..and here's a set of *new* issues I found while re-reading the draft...:
06-C01, 3.1.1 type Attribute
http://atompub.org/2005/03/12/draft-ietf-atompub-format-06.html#rfc.section.3.1.1
This has been mentioned before...: as far as I can tell, it's far easier
for recipients to process xhtml
David Powell wrote:
Two more things I've just noticed:
PersonConstructs aren't currently allowing extension elements.
anyForeignAttribute and anyForeignElement are currently not
used anywhere.
Proposal for test procedure:
- please publish an updated RNC file somewhere (on atomsub.org?)
- those who
Tim Bray wrote:
On Mar 17, 2005, at 1:08 AM, David Powell wrote:
But, I think that we should disallow xhtml attributes on the
xhtml:div
-1, unless you can provide actual real examples of actual real problems
that this prevents. --Tim
The underlying issue here (afaik) is that we've been told that
Henri Sivonen wrote:
On Mar 17, 2005, at 00:57, David Powell wrote:
c) disallow XHTML attributes on the xhtml:div wrapper, but
allow xml:lang.
If you allow declaring the language, why do you disallow declaring the
dominant writing direction (dir)? Shouldn't they be allowed or
disallowed
Robert Sayre wrote:
Graham wrote:
On 6 Mar 2005, at 5:15 pm, Paul Hoffman wrote:
Your assumption is completely wrong. The WG will review the next
draft before passing on to the IETF. The timing of the IETF meeting
is completely inconsequential.
Can you fill us in on what's happening with the
Tim Bray wrote:
On Mar 7, 2005, at 10:31 AM, Martin Duerst wrote:
for some implementors, HTML is actually easier, if they are handing a
chunk of bytes to an HTML rendering control, they'd rather not
reconstruct the syntax from the infoset, they'd rather just take an
opaque chunk of bytes.
I
Hi,
apparently, the new draft (06) wasn't finished in time for submission
before the meeting cutoff.
As this draft is the one that's supposed to be submitted for publication
(at least that's my understanding), wouldn't it make a lot of sense to
make the current edits available for review
Paul Hoffman wrote:
As this draft is the one that's supposed to be submitted for
publication (at least that's my understanding), wouldn't it make a lot
of sense to make the current edits available for review (*before* it
is committed after the end of the IETF meeting)?
Your assumption is
Thomas Broyer wrote:
Hi there,
First, let's introduce myself: I'm a 24 year-old French programmer
living in Dijon, France. Some day, I'd have liked to create my blog but
got stuck by all these RSS thingies and API stuff... I'm back now to
syndication as a user and programmer, and found Atom as
Robert Sayre wrote:
Agree w/ Tim. Also, HTML4 enjoys far better rendering support than XHTML
does.
That's true (in IE), but that's just a serialization problem. Nobody
said that recipients should emit that XHTML directly to HTML controls.
Best regards, Julian
--
green/bytes GmbH --
Lisa Dusseault wrote:
...
I think ADDMEMBER would be worthwhile if it did have more of an
extensibility model and provide the ability to support specialized
applications. For example, some calendar servers need to reject
non-iCalendar formatted submissions. ADDMEMBER reminds me a lot of
(fyi)
Original Message
...
To: [EMAIL PROTECTED]
...
Hi,
recently different communities (caldav/groupdav, atompup (protocol
part)) have been discussing how to use HTTP to author new resources when
the URL namespace is completely server-controlled, thus PUT just doesn't
fit
Sam Ruby wrote:
That's what I want to change. I've updated the Pace to make this
clearer. I replaced the abstract completely, and added one sentence to
the proposal.
New abstract:
Given that common practice is to include this element, making it
mandatory makes things clearer to both
Sam Ruby wrote:
Nor am I. The question is what's the best way to enhance the spec. One
alternative suggestion was made by Martin Dürst in
http://www.imc.org/atom-syntax/mail-archive/msg13531.html:
Note: It is important to make sure that correct namespace declarations
for XHTML are present.
Robert Sayre wrote:
Julian Reschke wrote:
So do you think we'll have to live with that, or should the spec be
clarified/changed to reduce the chance of people getting it wrong?
I think Sam's approach is best. The objections are all impractical
pedantry.
I think the proposal won't really help
Sam Ruby wrote:
Julian Reschke wrote:
Sam, thanks for the long reply. I'll try my best to dig it and to offer
constructive remarks...
To summarize my p.o.v.:
- the spec shouldn't require any specific container element for XHTML
content,
We continue to talk past one another. The above line
Paul Hoffman wrote:
...
Shouldn't we at least give content producers the hint that producing
XHTML content is preferred over HTML? (sorry if I'm opening a can of
worms here)
Why would one be preferred over the other? They both have their
strengths and weaknesses. We're not in the business of
Paul Hoffman wrote:
At 5:34 PM +0100 2/9/05, Julian Reschke wrote:
That's an interesting statement. Does type=HTML have *any* strengths
compared to type=XHMTL (expect being easier to produce if you don't
have XHMTL in the first place?).
That's certainly a big one. Also, many folks don't
Paul Hoffman wrote:
At 7:06 PM +0100 2/9/05, Julian Reschke wrote:
I'll agree that it's easier to produce for those who don't understand
XML. But shouldn't we recommend XHTML for those who *do* understand
XML/XHTML (and actually read the spec)?
Unless that suggestion gains better
Sam Ruby wrote:
Bill de hÓra wrote:
Sam Ruby wrote:
If this Pace is not adopted, the following predictions can be made:
1) Graham (who uses proper XML tools) will have to do more work.
I'd like to see a concrete example where this is a problem. As far as I
can tell, the content construct itself
Sam Ruby wrote:
Nothing changes for Tim, he can continue to produce the output he's
producing currently.
What Tim is syndicating does not match the content on his site. Without
this Pace, the div element would need to be considered part of the content.
What difference does this make in
Sam Ruby wrote:
Julian Reschke wrote:
(http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rfc.section.3.1.1)
The spec currently says:
If the value of type is HTML, the content of the Text construct
MUST NOT contain child elements, and SHOULD be suitable for handling
by software
Anne van Kesteren wrote:
Henri Sivonen wrote:
-1 on PaceXhtmlNamespaceDiv
-1 from me as well. It is hack which might be useful for publishing
systems (and perhaps aggregators) who do not use the right tools to
generate a valid Atom file anyway.
Same here: -1
--
green/bytes GmbH --
Tim Bray wrote:
On Feb 5, 2005, at 11:46 AM, Asbjørn Ulsberg wrote:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C XML
Robert Sayre wrote:
I would tend to agree. Can we have that regex go in the Pace itself?
That would make the proposal pretty much editorial, since the set of
allowed timestamps would be the same (right?).
As long as the set of allowed timestamps and their semantics is the
same, that's fine with
Robert Sayre wrote:
Norman Walsh wrote:
The 05 draft of the Atom format says:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date Constructs in
terms of W3C
Walter Underwood wrote:
--On February 4, 2005 11:18:17 AM -0500 Norman Walsh [EMAIL PROTECTED] wrote:
I know we're writing an IETF document, but I think there's going to be
a lot of off-the-shelf XML software that understands xsd:dateTimes and
I think it would be a lot better if we defined Date
Norman Walsh wrote:
/ Julian Reschke [EMAIL PROTECTED] was heard to say:
| - Neither xsd:dateTime nor RFC3339 are perfect for our needs, so we
| may have to profile one of them. In which case I'd prefer to stick
| with RFC3339.
Perhaps a compromise? Date Construct values MUST be valid xsd:dateTime
Tim Bray wrote:
On Feb 4, 2005, at 11:27 AM, Walter Underwood wrote:
Is this a joke? This is like saying that the order of the entries in my
mailbox is not significant. Note that ordering a mailbox by date is not
the same thing as its native order.
Except for, Atom entries have a *compulsory*
Bill de hÓra wrote:
If,
- 6.2 was dropped and probably
- the first sentence of the Pace was dropped,
- the rest of the 1st para was dropped down into 6.1
- there was some weasel wording about RFC3023 compliance
how would you feel about the rest of it?
...
I think the main issue here is first
Sam Ruby wrote:
Julian Reschke wrote:
Tim Bray wrote:
Just to see if it uncovered any problems, I twiddled the ongoing
software to generate a format-05 atom feed. It didn't uncover any
problems that I could see. Norm's RNC schema was very valuable in
debugging, not that there were many bugs
Hi,
(I raised this when reviewing draft 05 already, but I think this topic
deserves it's own thread)
Currently, the format spec has a normative reference to the protocol
spec (and also defines elements for the service URIs, for instance,
atom:introspection).
As far as I understand the IETF
Robert Sayre wrote:
Tim Bray wrote:
On Feb 1, 2005, at 1:05 PM, Julian Reschke wrote:
Currently, the format spec has a normative reference to the protocol
spec (and also defines elements for the service URIs, for instance,
atom:introspection).
I suggest this can and should be removed.
Agree
Thanks for the feedback, Robert...
Robert Sayre wrote:
- rel attribute is missing
The rel attribute is optional and the relation is considered to be
alternate in that case.
http://atompub.org/2005/01/27/draft-ietf-atompub-format-05.html#rel_attribute
Sam Ruby wrote:
Julian Reschke wrote:
atomTitle type=XHTML xmlns:xhtml=http://www.w3.org/1999/xhtml;
Less: xhtml:em lt; /xhtml:em
/atomTitle
(hope I got these right).
This is not only right, but also a good example of why many people would
prefer to have another element so that they don't have
Mark Nottingham wrote:
And, if you use XSLT, it's also possible to do it all in-stylesheet,
with or without links.
Safari (and probably other things) don't do XSLT.
Fair enough.
Safari is said to get a (libxml-based) XSLT engine in the next major
upgrade.
Best regards, Julian
--
green/bytes
Robert Sayre wrote:
'atom:head elements MUST contain at least one atom:link element with a
rel attribute value of alternate.'
Point taken. How about 'atom:head elements MUST contain at least one
atom:link element with a relation of alternate.'
Can't we just get rid of the defaulting? That would
Tim Bray wrote:
On Jan 31, 2005, at 4:37 AM, Robert Sayre wrote:
05-C05, 4.15.3 processing model
If the value of type begins with text/ the content of
atom:content MUST NOT contain child elements.
See 4.15.2: so is this a SHOULD or a MUST?
It's a MUST, and not an editorial change.
If it's a
Sam Ruby wrote:
...
I've reopened it minus the namespace restriction. I realize that Henri
is violently opposed to it, but his objection seem to reduce down to
cruft, and he seems to be in the minority. I see there to be a good
chance that rough consensus can be found on this pace.
...
For
Graham wrote:
On 30 Jan 2005, at 5:24 pm, Sam Ruby wrote:
I've reopened it minus the namespace restriction. I realize that
Henri is violently opposed to it, but his objection seem to reduce
down to cruft, and he seems to be in the minority. I see there to
be a good chance that rough consensus
Eric Scheid wrote:
On 31/1/05 4:43 AM, Julian Reschke [EMAIL PROTECTED] wrote:
The content SHOULD be XHTML text and markup that could validly appear
directly within an xhtml:div element.
...so making it explicit in the on-the-wire format seems to be
completely useless.
what's missing though
Robert Sayre wrote:
Tim Bray wrote:
On Jan 30, 2005, at 9:50 AM, Graham wrote:
2) An intermediary automatically c14nizes all URIs it processes. If
URIs come pre-c14nized from the publisher, this won't do any damage.
This is valid, but the problem is that these intermediaries are
currently
Tim Bray wrote:
On Jan 30, 2005, at 10:35 AM, Julian Reschke wrote:
That's an implementation issue that shouldn't affect the format.
Without any comment on the issue Julian was addressing, the above is
outrageous. Implementation issues are extremely material in discussion
of the format
Hi,
first I'd like to thank the editors for the good work.
The issues were collected after reading the spec top-to-bottom, and
trying to produce an Atom-05 feed from an existing RSS-1.0 feed through
XSLT. Most of them are editorial.
Best regards,
Julian
-- snip --
05-C01, 1.2 Example
Mark Nottingham wrote:
...
+1
There may be good reasons for atom:host and atom:info to be there, but
they aren't really obvious by reading the spec alone.
Best regards, Julian
--
green/bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
Tim Bray wrote:
On Jan 30, 2005, at 12:21 PM, Julian Reschke wrote:
The issues were collected after reading the spec top-to-bottom, and
trying to produce an Atom-05 feed from an existing RSS-1.0 feed
through XSLT. Most of them are editorial.
Good stuff, Julian.
Thanks.
If the value of type
Robert Sayre wrote:
Tim Bray wrote:
On Jan 30, 2005, at 12:09 PM, Robert Sayre wrote:
We should either explicitly allow application/xml in section 2, or
remove this element. I'm not sure which I prefer.
atom:info is useful during transformations. Tossing atom:info will
result in
Sam Ruby wrote:
I also don't like the restriction on where namespace declarations must
be placed, but overall, I believe that the pace is a good idea.
Consumers don't want full web pages (complete with html head and titles)
as summaries, they want something that they can *insert* into a web
page.
Martin Duerst wrote:
...
Bjoern was making a vaild, but fine, point: Because we decided to
refer to RFC2396bis, rather than to RFC2396, we already have bought
into the fact that RFC2396bis allows percent-encoded domain names,
and thus essentially requires IDN support. (apart from the basic
fact
Paul Hoffman wrote:
At 5:03 PM -0800 1/24/05, Roy T. Fielding wrote:
Why don't you just invent a status of incomplete and leave
them off the table until completed? It doesn't make sense to
close issues that are not resolved one way or another.
It does make sense this late in the process. As we
Tim Bray wrote:
If there were no further discussion: It's hard to see how to avoid
adopting this now that IRIs are standards-track RFC. -Tim
I saw some concerns (with which I agree) that requiring the presence of
an IDN library is problematic. As far as I can tell, it's likely to be
ignored by
Martin Duerst wrote:
At 17:16 05/01/25, Julian Reschke wrote:
Also; I sypmathize with supporting IRI, but that shouldn't mean it
needs to replace any usage of URIs
Every URI is an IRI by definition. So all URIs that are in use can be
used with Atom without any problems even if the spec says we
Norman Walsh wrote:
...
|Any element in an Atom Document MAY have an xml:base attribute. XML
|Base [W3C.REC-xmlbase-20010627] processing MUST be applied to any
|relative reference [RFC2396bis] present in an Atom Document. This
s/relative reference/relative URI reference/
Relative
100 matches
Mail list logo
