At 02:25 07/03/23, James M Snell wrote:
It is not year clear if there has been enough independent implementation
of the specification to justify publishing it as a proposed standard.
There is no need for implementations when going to Proposed Standard
(of course, they never hurt). There is a
At 16:13 07/01/05, Asbj\x8F\xD3n Ulsberg wrote:
On Thu, 04 Jan 2007 17:00:29 +0100, Jan Algermissen
[EMAIL PROTECTED] wrote:
on the NewsML list, an issue came up that due to they lack of a MIME
type for NewsML using NewsML as Atom content is somewhat problematic[1];
I think this is the
At 13:14 06/12/13, James M Snell wrote:
I think atom.entry and atom-entry are equally ugly; atom.entry would,
however, appear to be more consistent with typical mime conventions.
The dot is used for prefixes like vnd. (vendor) and so on.
In the case of atom entries, atom-entry is more in line
At 10:32 06/12/11, Franklin Tse wrote:
Option B) New Entry media type
application/atom.entry+xml
+1
+1
#-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University
#-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
At 07:50 06/11/10, Asbj\x8F\xD3n Ulsberg wrote:
A good example is the XHTML namespace URI:
http://www.w3.org/1999/xhtml
Yes, this is a good example in general, but misses one important
point. It should say explicitly that the namespace URI is
http://www.w3.org/1999/xhtml. Why? Because
At 04:10 06/10/03, Julian Reschke wrote:
Independantly of that, what do we do with all the normative references to
proposed standards...:
RFC3987: [PROPOSED STANDARD] -- intended standards level of DRAFT incompatible
with this document's standard level!
I've definitely thought about moving
At 10:43 06/07/10, Robert Sayre wrote:
Hi Lisa,
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
At 06:34 06/04/26, James M Snell wrote:
A couple more link rel test cases:
http://www.snellspace.com/public/linkreltest.xml
See the bottom of: http://www.intertwingly.net/wiki/pie/LinkConformanceTests
Just a short comment: the use of unregistered,
(see
At 10:02 06/05/31, James Holderness wrote:
Robert Sayre wrote:
of Use IRI:Compare, Use String::Compare, or The spec doesn't say, so
you may use whatever you prefer.
The URI/IRI specs say use whatever you prefer. If you don't like
that, have James add it to his revision of 4287. :)
Thanks.
At 04:37 06/05/27, Robert Sayre wrote:
Huh, I personally feel that the comparison ladder is better. Sort of
like, if it comes down to that, we can't help you, even for atom:id.
The WG definitely felt simple string comparison was needed for
atom:id, so we spent *a lot* of time on that text.
I
Hello Robert,
It's not the IETF which wants to move this on on Standards Track,
it's (currently) James as an individual submitter. The IESG just
did what it does for all such requests from individuals: Put the
document out for IETF Last Call and tell the relevant mailing lists
about it.
Now
At 19:17 06/04/04, Anne van Kesteren wrote:
Quoting James Holderness [EMAIL PROTECTED]:
If `Content-Location` is not usable or can't be used consistent on a website
(for example, using it for both Atom and HTML content) I suggest we specify
something that is consistent with what browsers do.
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 characters.
This is indeed
At 18:49 06/03/17, Bjoern Hoehrmann wrote:
* Martin Duerst wrote:
When looking with a microscope, you will find some little
differences, because xs:anyURI was described before the IRI
spec (RFC 3987) was approved. These differences are:
1) xs:aryURI also allows spaces and a few other ASCII
At 00:42 06/03/17, Norman Walsh wrote:
/ Thomas Broyer [EMAIL PROTECTED] was heard to say:
| RFC 3987 says (section 1.2 Applicability):
|For example, XML schema [XMLSchema] has an explicit type
|anyURI that includes IRIs and IRI references. Therefore, IRIs
|and IRI
At 08:42 06/03/15, David Powell wrote:
Not sure if this is a known bug, but I just noticed that the RelaxNG
grammar doesn't accept atomCommonAttributes (eg xml:lang) on the
atom:name and atom:uri and atom:email elements used within
Person constructs.
For atom:uri and atom:email at least, not
At 16:45 05/10/02, James M Snell wrote:
http://www.w3.org/2005/Atom-extensions works for me... assuming, of
course, that Those-Who-Officially-Assign-Such-Things go along with it.
Tim and Paul know who to contact.
The original .../ace URI was just a working thing pitched with full
knowledge
At 07:04 05/10/03, Walter Underwood wrote:
--On October 2, 2005 9:35:28 AM +0200 Anne van Kesteren
[EMAIL PROTECTED] wrote:
Having a file and folder of the same name is not technically possible.
(Although
you could emulate the effect of course with some mod_rewrite.)
Namespaces aren't
At 22:58 05/08/23, Antone Roundy wrote:
On Monday, August 22, 2005, at 09:54 PM, A. Pagaltzis wrote:
For this application, I would do just
that, in which case, as a bonus, non-UTF-8 streams would get to
avoid resending the XML preamble over and over and over.
Of course, if you do that, you
At 02:15 05/08/23, A. Pagaltzis wrote:
Using a character which is illegal in XML and can never be part
of a well-formed document as a separator is a clever way to avoid
having to do *any* parsing *whatsoever*. You just scan the stream
for the character and start over when you see it, end of
At 03:12 05/07/08, Paul Hoffman wrote:
We are signing the bits only, not some interpretation of the bits. That
is true for the xml:base, the xml:lang, the xml:something-else, and so on.
Just a clarification that I may have made previously: XML Canonicalization
(both kinds) convert to UTF-8
At 10:26 05/07/01, Paul Hoffman wrote:
To be added near the end of Section 5.1 of atompub-format:
Section 6.5.1 of [W3C.REC-xmldsig-core-20020212] requires support
for Canonical XML. Atom Processors that sign Atom Documents MUST
use Canonical XML.
Hello Paul,
The rest of your
At 03:21 05/06/24, Tim Bray wrote:
On Jun 23, 2005, at 9:12 AM, Eric Scheid wrote:
If there are problems
that require repair, I don't want to wait two more weeks to find out
about them. This is very disappointing. -Tim
we can start with these two...
Hello Andreas,
There was quite some discussion between Keith Moore and me
and a few others about how to serve email in the context of
draft-duerst-archived-at-XX.
See e.g. http://www.imc.org/ietf-822/mail-archive/msg05486.html
and many older threads in the same archive.
The general idea seems
At 16:09 05/05/22, Anne van Kesteren wrote:
Robert Sayre wrote:
I think the last paragraph of RFC3987, section 5.1 already says that :)
http://rfc.net/rfc3987.html#s5.1.
That also says that fragment components should be excluded. Is that true
for Atom?
It says:
When IRIs are compared
Hello Thomas,
At 07:34 05/05/22, Thomas Broyer wrote:
I'm sorry to raise this issue back again but...
The Atom Publishing Protocol defines SOAP bindings. This (in my mind)
means there will be WSDL files over there. WSDL rely on XML Schema which in
turn are limited to deterministic content
At 08:47 05/05/20, Eric Scheid wrote:
On 19/5/05 10:41 PM, Tim Bray [EMAIL PROTECTED] wrote:
We suggest that there may be WG consensus in favor of changing the
format spec to make atom:id a required child of atom:feed. (Text not
provided, we trust the editors to figure out the correct way
(BI just had another idea:
(B
(BWhy don't we use a totally different element name, rather than div?
(BWhat about e.g. wrapper? This could be pro-forma in the XHTML Namespace,
(Bbut as this isn't handed over to the XHTML rendering engine (as far as
(BI understand), it wouldn't matter. Also,
/05, Martin Duerst wrote:
What's the difference between IETF consensus (for which you gave a -1)
and it's up to the IESG (which seems what you think we should let happen)?
From RFC 2434:
IESG Approval - New assignments must be approved by the IESG, but
there is no requirement
At 01:08 05/05/09, Tim Bray wrote:
On May 7, 2005, at 3:29 PM, Robin Cover wrote:
The publication of a new Implementation Guideline by the
Open Archives Initiative (OAI) compels me to suggest once
again [1], as Norm Walsh [2], Bob Wyman [3], and others have
done before, that the name
Hello Paul,
What's the difference between IETF consensus (for which you gave a -1)
and it's up to the IESG (which seems what you think we should let happen)?
In my view, IETF consensus is another way of saying the IESG has the
last word. If there is a better way to express this in the spec, then
At 00:12 05/05/07, Bob Wyman wrote:
Right. We have abstract feeds and entries and we have concrete feeds
and entries. The abstract feed is the actual stream of entries and updates
to entries as they are created over time. Feed documents are concrete
snapshots of this stream or abstract feed of
At 11:50 05/05/06, Sam Ruby wrote:
Tim Bray wrote:
+1
There are people who want to publish feeds without rel=alternate
links. I'm against telling people they can't do something they want to do
without strong reasons, as in loss of interoperability. I don't see the
reasons here as strong
At 02:27 05/05/04, Thomas Broyer wrote:
Martin Duerst wrote:
At 03:33 05/04/29, Alexey Melnikov wrote:
If the value is text, the content of the Text construct MUST NOT
contain child elements. Such text is intended to be presented to
humans in a readable fashion. Thus, Atom
At 03:33 05/04/29, Alexey Melnikov wrote:
The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-08.txt
3.1.1.1 Text
If the value is text, the content of the Text construct MUST NOT
contain child elements. Such text is intended to be presented to
At 11:10 05/04/12, Porges wrote:
OK, first-time poster :)
I was just thinking about IRIs recently and thought about a possible
source of ambiguousness. If the URI element can be EITHER an IRI or a
URI, then:
urihttp://example.com/200%25equalsZero/uri
This is both a valid IRI and a valid URI,
At 17:34 05/04/09, Julian Reschke wrote:
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:
+1 to adding these kinds of clarifications and examples to the spec!
Regards, Martin.
At 08:02 05/04/08, David Powell wrote:
The inheritance of @xml:lang and @xml:base creates a lot of
complexities for an implementation. When they are used in combination
with atom:source, things get
+1
At 02:59 05/04/05, Antone Roundy wrote:
http://www.intertwingly.net/wiki/pie/PaceFeedIdOrSelf
Of course I'm also for making an alternate link for a feed a
MAY rather than a MUST.
Regards, Martin.
At 07:57 05/04/03, David Nesting wrote:
Why isn't this requirement a may instead of a must? I can see having
a link with rel=alternate if indeed a alternate version does exist. It
does not
Hello Dan,
The problem I have with using web is that there is a pars pro
toto (or probably rather the other way) problem here. I.e.
the Web is defined by *all* the resources identified by an URI/IRI,
whereas the element we are trying to name points to just one of
them.
Given all the proposals, my
I agree. This allows images to be relative. Please note
that in both cases, fragments are allowed, although I don't
know any image format for which they'd be useful at the moment.
Regards, Martin.
At 09:38 05/03/19, David Powell wrote:
From draft-06:
The atom:icon element's content is an IRI
Mildly put, I was never a big fan of the xhtml:div wrapper.
But if xml:lang is disallowed on the xhtml:div wrapper, this
makes even less sense to me. If Atom processors can handle
(i.e. correctly inherit) xml:lang from atom: elements into
the xhtml: elements as they are required to, I don't see
At 08:36 05/03/07, Tim Bray wrote:
I agree also, but 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. So we really
At 06:52 05/03/07, Julian Reschke wrote:
Anyway, I recently made a much more modest request that the spec should
state that XHTML is preferred over HTML (because many recipients will not
be willing to process tag soup, so in the best case formatting is lost). It
seems that we can't even get a
At 05:37 05/03/08, Julian Reschke wrote:
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
At 01:44 05/02/23, Paul Hoffman wrote:
This list should still be focused on the format draft. As our document
editors toil away diligently, we can still offer editorial suggestions.
This is also a reasonable time to start creating format extensions and
talking about them here.
Hello Paul,
(BAt 04:31 05/02/23, Bob Wyman wrote:
(BAt PubSub, we allow users to subscribe to RSS/Atom entries that contain
(Buser-specified URIs. (Using a query like: URI:nytimes.com) Users of this
(Bfeature have often asked us to augment the entries we publish by attaching
(Bthe URIs we discover to
(BAt 20:44 05/02/17, Bill de h$B".(Bra wrote:
(B
(B Martin Duerst wrote:
(B At 19:03 05/02/16, Bill de h$Bec!V(Bra wrote:
(B
(B The point I'm seeing here is that creating markup using string
(Bconcats is inherently fragile. No surpise there. Wrt namespaces, fragility
(BAt 19:03 05/02/16, Bill de h$B%b(Bra wrote:
(B
(B As long as it's XML and otherwise conformant, I think it's fine.
(B Probably not. Do you and Julian and Anne and Henri approve?
(B I don't see how I would want to complain about how you generate
(B your stuff, as long as the result
(BAt 01:35 05/02/11, Sam Ruby wrote:
(B
(B Julian Reschke wrote:
(B
(B Nor am I. The question is what's the best way to enhance the spec. One
(Balternative suggestion was made by Martin D$BS(Bst in
(Bhttp://www.imc.org/atom-syntax/mail-archive/msg13531.html:
(B "Note: It is
[I appologize that this comes late. I was ill last week.]
I'm also still not convinced about this one. It was introduced
with a very good motivation, namely that it would increase the
chance that namespaces would be used correctly. After the changes,
what I understand is left is the following:
At 23:36 05/02/08, Julian Reschke 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)
I'd be very much in favor of that. The first step is to order the sections
so that XHTML comes first. I
At 22:59 05/02/08, Julian Reschke wrote:
http://www.intertwingly.net/wiki/pie/PaceXhtmlNamespaceDiv
I have looked at this pace only just very recently, after
following the discussion. So I first want to make sure I
get the current status of this proposal right.
As I currently read it, it does:
1)
Clarifying some details based on my write-manytimes understanding
of IRIs (RFC 3987).
At 07:15 05/02/01, Robert Sayre wrote:
Graham wrote:
I don't know much about IRIs. Is it possible to express them as URIs?
My read-the-draft-once understanding is that it is always possible to
convert an
At 08:25 05/02/01, DJWS wrote:
At 22:25 31/01/2005, Graham wrote:
I don't know much about IRIs. Is it possible to express them as URIs?
As far as I understand, and this is my problem : I cannot have a formal
response on the following.
- there are various way to support a non ASCII IRI (the
At 17:09 05/01/31, Henri Sivonen wrote:
On Jan 31, 2005, at 03:00, Graham wrote:
Software displaying this text SHOULD remove white-space at the
beginning and end; collapse white-space between words; and disregard line
break, tab and other formatting characters. in 3.1.1 (TEXT).
+1 with the
At 00:38 05/02/01, Tim Bray wrote:
On Jan 31, 2005, at 5:37 AM, Bjoern Hoehrmann wrote:
http://www.w3.org/MarkUp/2004/xhtml-faq#xmlspace cites a quite different
opinion on this matter...
Yes, well that opinion is (a) specific to HTML and (b) wrong. I'm amazed
that the W3C allowed that to be
Sorry, this was way back, but caught my eye again.
At 11:39 05/01/27, Sam Ruby wrote:
Martin Duerst wrote:
At 01:51 05/01/26, Asbj n Ulsberg wrote:
On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby [EMAIL PROTECTED]
wrote:
2. Why MUST a feed point to an alternate version
At 08:46 05/02/01, Mark Nottingham wrote:
[[[
x. Managing Feed State
Atom Processors MAY keep state (e.g., metadata in atom:head, entries)
sourced from Atom Feed Documents and combine them with other Atom Feed
Documents, in order to facilitate a contiguous view of the contents of the
feed. The
I have just looked at the text in question in -05.txt,
and read through the discussion. I'll give my comments
here, but they are not specifically on this mail.
First, for me, the goal of having reproducible id comparison
is most important; this is the basic requirement.
Second, given that there
Hello Robert,
Thanks for your questions, and for studying IRIs so carefully.
At 09:15 05/01/29, Robert Sayre wrote:
IRIs are a step forward and important to include in the spec, but they
also worry me. In RFC3987, I read the following:
The approach of defining a new protocol element was chosen
At 13:01 05/01/26, Eric Scheid wrote:
It's only clear what's going on when the reader juxtaposes the two sections,
and realises that the concept named 'type' in section [3.1.1] is not the
same concept named 'type' in section [3.5.2]. Without that juxtaposition,
the reader might well never realise
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 use IRIs.
Replacement
(BHello Bjoern,
(B
(BFor more details, please see my earlier message at
(Bhttp://www.imc.org/atom-syntax/mail-archive/msg12198.html.
(BPlease comment on the specific points mentioned there.
(B
(BRegards, Martin.
(B
(BAt 16:15 05/01/25, Bjoern Hoehrmann wrote:
(B
(B * Martin Duerst
At 07:35 05/01/26, Robert Sayre wrote:
Walter Underwood wrote:
6. Client processing requirements
Atom feeds served over HTTP MUST be well-formed XML 1.0, as defined in
Section 2.1 of the XML specification
http://www.w3.org/TR/REC-xml/#sec-well-formed. Furthermore, the concept
of XML
At 01:52 05/01/26, Paul Hoffman wrote:
At 9:16 AM +0100 1/25/05, Julian Reschke wrote:
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 developers of clients that run on somwehat constrained
(BAt 01:51 05/01/26, Asbj$BS(Bn Ulsberg wrote:
(B
(B On Wed, 12 Jan 2005 16:54:27 -0500, Sam Ruby [EMAIL PROTECTED]
(B wrote:
(B
(B 2. Why MUST a feed point to an alternate version. [...]
(B
(B I'm -1 on removing this restriction.
(B
(B I thought we came to a sort of consensus
At 09:17 05/01/25, 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
Some good news:
The IRI spec is now published as RFC 3987 (Proposed Standard,
http://www.ietf.org/rfc/rfc3987.txt).
The update of the
At 06:38 05/01/25, Sam Ruby wrote:
Henry Story wrote:
We are all working together on the proposal, in an iterative fashion.
This is very similar to the way one develops software projects in Agile
or Extreme programming methodology. First one starts with a prototype.
One gets the major
At 17:47 05/01/17, David Powell wrote:
Reading the XML spec, I'm not clear that we're allowed to restrict the
inheritance of xml:lang?
From the spec:
The intent declared with xml:lang is considered to apply to all
attributes and content of the element where it is specified, unless
overridden
At 05:15 05/01/18, David Powell wrote:
Monday, January 17, 2005, 6:11:22 PM, you wrote:
Suppose Joi Ito wants to list his name in
Japanese but still write in English; or the the reverse.
Let's hope he doesn't want to provide a name in more than one language.
Well, I can definitely imagine
At 04:54 05/01/18, Danny Ayers wrote:
It's been a long time since I looked at XML schemas, but would be
possible to express the content type attribute at all neatly using a
complex type? I imagine the TEXT | HTML | XHTML part would be
straightforward, but doesn't the | pretty/much;anything option
At 05:16 05/01/18, David Powell wrote:
Monday, January 17, 2005, 7:32:48 PM, you wrote:
There are some fields in Atom which are language-independent or
neutral and thus it might be useful to explicitly prevent the use of
xml:lang tags for these elements or simply state that they have
At 06:54 05/01/13, Sam Ruby wrote:
Norman Walsh wrote:
2. Why MUST a feed point to an alternate version. What if the feed is all
I publish?
Deja vu:
http://www.imc.org/atom-syntax/mail-archive/msg08836.html
I'm -1 on removing this restriction.
I don't see any clear justification in the
At 22:33 05/01/11, Danny Ayers wrote:
On Tue, 11 Jan 2005 16:50:56 +0900, Martin Duerst [EMAIL PROTECTED] wrote:
http://www.intertwingly.net/wiki/pie/PaceIRI
I like it a lot in principle, my only concern is the dependency on an
IDN library (nicely put together Pace, btw).
Thanks!
As noted
I have completed (as far as I'm concerned) PaceIRI.
The proposal is simple, namely to allow IRIs wherever the spec
currently allows URIs. I have given details of what needs to be
changed in the spec for that to happen. If anything is unclear,
I'm glad to help out the editors.
As far as I remember,
At 05:59 05/01/09, Robert Sayre wrote:
http://atompub.org/2004/10/20/draft-ietf-atompub-format-03.html#rfc.section.5.10.2
If the value of type begins with text/ or ends with +xml, the
content SHOULD be local; that is to say, no src attribute should be provided.
If you want to suggest language
At 16:04 05/01/11, Martin Duerst wrote:
I have completed (as far as I'm concerned) PaceIRI.
Just to help everybody to look at it faster, here is the URI/IRI:
http://www.intertwingly.net/wiki/pie/PaceIRI
Sorry I forgot.
The proposal is simple, namely to allow IRIs wherever the spec
currently
79 matches
Mail list logo
