* Elliotte Harold wrote:
By the way, http://www.iana.org/assignments/relation/ is 404. This is
referenced in the Atom 1.0 spec. It doesn't really need to be resolved,
but it would be nice to put something there.
Interesting. http://www.iana.org/assignments/link-relations.html is the
right
* Andreas Sewe wrote:
This raises the question, however, whether it would be worth pointing
out in the I-D that quoting a parameter value is allowed. Implementors
might otherwise produce code that does treat
application/atom+xml;type=feed and application/atom+xml;type=feed as
different.
* Andreas Sewe wrote:
While RFC 2045 specifically allows quoted parameter values and defines
application/atom+xml;type=feed to be equivalent to
application/atom+xml;type=feed, RFC 4288 states that '[t]here is no
defined syntax for parameter values. Therefore registrations MUST
specify
* Bob Wyman wrote:
Did the +xml convention ever get formalized in some RFC? I know we all
*think* that tacking +xml onto the end of something means that it is some
use of XML, however, if I remember correctly, this little bit of syntax has
never actually been formalized... Or have I missed
* 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.
Thoughts?
I think that XHTML does not define an 'unicode-bidi' attribute.
Do you mean, for 'unicode-bidi', as defined
* James M Snell wrote:
http://www.ietf.org/internet-drafts/draft-snell-atompub-feed-license-06.txt
I do not understand section 4, it says the security considerations of
RFC 4287 apply; the only consideration there that could apply is that
IRIs are used, and as such considerations of RFC 3987
* James M Snell wrote:
Another concern that was raised to me by a colleague is that the license
resource being pointed to could change over time, meaning that the
license being referenced today may not be the same license being used
tomorrow even tho URIs may be exactly the same. If the license
* Martin Duerst wrote:
At 02:30 06/03/20, Bjoern Hoehrmann wrote:
In Schema 1.1 it is not possible for a xsd:string to be no xsd:anyURI.
Can you explain? It seems you are saying that all xsd:strings are
also xsd:anyURIs, but that seems going a bit too far.
Yes, that's exactly what the XML
* 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. I think a new type is necessary if
* 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 characters
that are not allowed in URIs nor
* Tim Bray wrote:
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature and further
processing would be
* Graham wrote:
the XML processor must report the error to the application and that the
processor is not required by the XML specification to continue
processing; doing so is however an optional feature and further
processing would be implementation-defined
vs
Once a fatal error is detected,
* Tim Bray wrote:
If you encounter a busted tag on the Nth entry, per the XML spec
that's a fatal error and you can't process any more.
That's a bit misleading, a fatal error just means that the XML
processor must report the error to the application and that the
processor is not required by
* Robert Sayre wrote:
Anyone seen it or know where it will be found?
The IANA registry? It will be created some time between now and the
publication of the RFC. Same goes for the Atom media type and any
other pending IANA actions.
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] ·
* Sjoerd Visscher wrote:
A while ago we had a discussion about how xml:base should be used.
We didn't reach a conclusion, but I think we need to act.
How to use xml:base is a matter of the xml:base specification
and (less so) the resource identifier specifications. If you
think xml:base is
* Sjoerd Visscher wrote:
It would be really cool if you would move the xml:base of the entry to
the div, but as you have 2 divs per entry I can imagine you don't want
to do that. Or you could change the base URI to f.e.
When/200x/2005/08/14/Java-Net-Terms.atom (even if that doesn't
* Tim Bray wrote:
Implementors are advised that there is a common class of error in
[...]
Sorry but this is ridiculous; if we say X MUST Y even though we know
that many X won't Y we are abusing RFC 2119 terminology and make it
much more difficult to evangelize 100% compliance, since this
* Paul Hoffman wrote:
You can't compare an IRI with a non-IRI. So, if you are handed an
non-IRI (as in, an IRI-looking string that has whitespace around it),
should you fail immediately or try harder? I propose trying harder,
but I am open to just fail.
Well, if we expect that many content
* Dave Pawson wrote:
Even if we decide that whitespace is not significant, I do believe that
having the feedvalidator issue a warning in such cases is appropriate.
+1
What is the IETF version of an errata sheet? Is that the right
place to tackle this?
For RFCs see
* Sjoerd Visscher wrote:
And that's why you can't use it as a reference to your site.
That depends a bit on same-document reference processing of Atom
processors. If the Atom processor assumes the link refers to some
web site and passes the absolute reference to some other user agent
there would
Hi,
http://www.ietf.org/internet-drafts/draft-ietf-atompub-format-10.txt
refers to white-space a couple of times but does not define this term.
The exact definition is important to know for 4.1.3.3 item 6 and I would
like to avoid to /assume/ that this means any number of U+0020, U+0009,
* A. Pagaltzis wrote:
I like both versions for different reasons. Thanks, of course,
for providing a HTML rendition – I, too, have to say I find the
ASCII versions very 1989. (I use rfc.net to read RFCs so there is
at least a modicum of formatting and actual, you know, links.)
There is
* Dan Brickley wrote:
http://www.w3.org/2001/sw/BestPractices/HTML/samples/atom/a1.xml
`Content-Type: text/xml; qs=0.9`. Hurray...
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim ·
Hi,
I think it would be helpful if section 8 (Security Considerations)
of the latest draft includes a reference to section 5 Securing Atom
Documents.
regards,
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 ·
* Paul Hoffman wrote:
This is rarely done in RFCs. Further, Section 5 is clearly listed in
the table of contents, and someone who intends to implement the
protocol probably has at least skimmed the document before they read
the details in the Security Considerations section.
Well, I think the
* Henri Sivonen wrote:
I'm wondering which validator was used for testing the Atom
RNG+Schematron schema. Which validators support Compact Syntax with
embedded Schematron? I am particularly interested in Java solutions.
http://www.topologi.com/products/validator/ is said to support it.
--
* David Powell wrote:
I'm asking this because I really don't know whether parameters are
supposed to be allowed in the type attribute or not.
http://www.imc.org/atom-syntax/mail-archive/msg08283.html
--
Björn Höhrmann · mailto:[EMAIL PROTECTED] · http://bjoern.hoehrmann.de
Weinh. Str. 22 ·
* Tim Bray wrote:
There are a couple of places where we use uri in the markup,
specifically the atom:uri element (3.2.2) and the uri attribute of
atom:generator (4.2.5).
In both cases they're not actually URIs, they're IRIs, so the name is
WRONG, except for nobody knows what an IRI is so
* Dan Brickley wrote:
In both cases they're not actually URIs, they're IRIs, so the name is
WRONG, except for nobody knows what an IRI is so renaming them iri
would be confusing, and anyhow everyone thinks of URLs not *RIs, but
naming them url would be wrong too, so why don't we actually
* Dan Brickley wrote:
I think the question is which of these is meant by the web:
I encourage Atom to follow the WebArch REC, let's call it (d),
http://www.w3.org/TR/webarch/#intro
[[
The World Wide Web (WWW, or simply Web) is an information space in which
the items of interest, referred to as
* Tim Bray wrote:
I tend to agree as well; in this case, the fact that this is an XML
vocabulary is probably more relevant than the fact that it's an IETF
RFC. So can we please have a Pace to call out to XSD? I'm pretty sure
that implementors would just use the libraries and The Right Thing
* Paul Hoffman wrote:
Although I can't find it specified in the current draft, there used
to be a rule that you weren't supposed to use the same atom:id more than
once in a single feed.
The current draft says:
5.8 atom:id Element
The atom:id element is an Identity construct that
* Martin Duerst 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 published. -Tim
Would you mind explaining why you think
* Robert Sayre wrote:
If I tell NetNewsWire to GET something in the subscribe dialog, my
dispatching instructions are clear. Everything is a feed. Making up
rules for application/xml, text/xml, and application/octet-stream will
require superceding some RFCs that I'd rather not mess with.
What
* Julian Reschke wrote:
The big difference here is that XMLNS uses IRIs/URIs as identifiers and
only for that. However, what is an XSLT that transforms Atom content to
HTML supposed to do when it encounters a IRI which isn't a legal URI?
http://www.w3.org/TR/xslt#section-HTML-Output-Method
* Julian Reschke wrote:
The big difference here is that XMLNS uses IRIs/URIs as identifiers and
only for that. However, what is an XSLT that transforms Atom content to
HTML supposed to do when it encounters a IRI which isn't a legal URI?
http://www.w3.org/TR/xslt#section-HTML-Output-Method
* Robert Sayre wrote:
I'm very -1 on this, since it makes the definition of the Atom format an
HTTP message, rather than an XML document.
It seems common practise to include requirements for implementations of
a format into the specification of the format. Why should these be kept
separate? In
* Danny Ayers wrote:
To be inserted:
{{{
Section 2. Atom Documents
Atom processors MAY interpret unprefixed attribute names as their
namespace-qualified equivalents.
If they do, then all Atom attribute names MUST appear in the Atom namespace.
}}}
This does not make much sense to me, it is
* Martin Duerst wrote:
Not yet taken up by the WG, depends on the discussion that comes with
this call. Same rules as all the others: there has to be a positive WG
consensus that each adds to the base specification. -Tim
+1, at least for atom:language inside the header. For elements,
* Antone Roundy wrote:
The difference is that we (at least some of us) don't want atom:link
used for things like this:
link rel=stylesheet type=text/css href=/stylesheets/menu.css
We want it used only for links that are meant to be activated by the
user and result in visiting the resource.
I
40 matches
Mail list logo
