Re: Atom Bidi Draft Update - Informal Last Call
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 well-defined need when going from Proposed Standard to Draft Standard, but that's way in the future. Regards, Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Additional 'namespace' attribute on content element?
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 case with most of the more interesting XML applications out there. The more interesting XML applications out there should get a proper MIME type, that's all. Nothing wrong with Atom in this case, imo. Sorry, wrong. Using +xml at the end of a Mime Type is a good convention, but it is only a convention. There is no requirement for a Mime Type that uses XML to end in +xml. Also, the +xml convention was established several years later than XML itself. So I think that Atom is a bit out on it's egde if it says 'if you don't have a +xml Mime Type, you're not XML'. Regards,Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Atom Entry docs
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 with the convention in other types. Regards,Martin. - James Tim Bray wrote: [snip] (James, did you really mean atom.entry with the ugly dot?) -Tim #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
RE: Atom Entry Documents
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]
Re: [atom-syntax] [RFC 4685] uri in xml namespace
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 somebody by chance may arrive at this page from another URI, such as http://Www.w3.org/1999/xhtml (Opera and Firefox convert this to http://www.w3.org/1999/xhtml, probably due to the Latin/Cyrillic confusion/scare a while ago, but IE doesn't). Regards,Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Atom Syndication Format To Draft Standard?
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 that a level forward, but that may take another few months or so. Regards,Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Protocol Action: 'Atom Threading Extensions' to Proposed Standard
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 that the namespace is not a problem. I see Sam Hartman raised the issue. What was the resolution? Could the draft advance to Draft- or Full-Standard in that namespace? I looked at that namespace shortly. It seems that it would be easy to change the owners to make clear that this is owned by the IETF. This can be done whenever it's needed. A purl namespace in and by itself isn't any better or worse than a W3C namespace. Regards,Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Link rel test cases
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 http://www.iana.org/assignments/urn-namespaces) made-up urn namespaces such as linkreltest in idurn:linkreltest:feed/id doesn't really match well with the fact that atom is an IETF format, and tests are supposed to be correct and conforming by themselves. Regards, Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Link rel test cases
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. That's not how I read RFC3987, but I'm happy to accept your interpretation. Well, RFC 3987 (and 3986) don't *exactly* say use whatever you prefer, but for the case at hand, what they say comes pretty close. What they try to do is give advice on what kind of normalization or comparison function(s) is/are adequate in which case. Given that it's difficult to immagine every possible case in advace, the advice they give unfortuanetly has to be somewhat vague. BTW, as a co-author of RFC 3987, I of course appreciate any suggestion on how to make it clearer, and any suggestions for fixes or changes (should they be necessary). These should be directed to [EMAIL PROTECTED] Regards, Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Link rel test cases
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 think for simple IDs, where there is no expectation of resolution, character-by-character comparison is better. But either way, the spec is the way it is now. I don't feel that effort would pay off here, at all. Especially since a consumer that matched HTTP://www.IANA.org:80/assignments/relation/alternate would be in error. That's ridiculous standards weenie stuff, don't you think? Yes, a content producer that expected a) HTTP://www.IANA.org:80/assignments/relation/alternate to always be different from b) http://www.iana.org/assignments/relation/alternate would be stupid. But on the other hand, a content producer that expected a) and b) to always be treated the same would be ridiculous, too. The conclusion is that a content producer that uses HTTP://www.IANA.org:80/assignments/relation/alternate at all does something wrong. Regards,Martin. #-#-# Martin J. Durst, Assoc. Professor, Aoyama Gakuin University #-#-# http://www.sw.it.aoyama.ac.jp mailto:[EMAIL PROTECTED]
Re: Feed Thread in Last Call
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 it's your (and everybody else's) turn to tell the IESG what you think about this draft. A short, but clearly argued and nicely worded mail, with some easy-to-follow pointers to further material, is all that is needed. This may say okay with Standards Track iff these things get fixed or should be experimental because ... or even too controversial for an individual submission, needs a WG. The time you invest in this email will be a lot better spent than writing yet another mail to James and this list. Lisa (the sponsoring AD) and the rest of the IESG will then look at all the input they get, and will make a decision. Regards,Martin. At 07:03 06/05/17, Robert Sayre wrote: On 5/16/06, Paul Hoffman [EMAIL PROTECTED] wrote: At 4:33 AM +0200 5/16/06, Robert Sayre wrote: I thought the working group was fairly clear about the dubious value and placement of these attributes, For the benefit of Lisa, who is the sponsoring AD for this document, please list links to those messages. James changed the document in response to those messages. That should be enough. Maybe she could ask James about them. It's not my obligation to spelunk for them, and it's certainly not your place to start making demands like that. So you don't think they're important or needed, and then WG doesn't have consensus on them. Quite true, but it is true because there has never been a call for consensus on the document, and there won't be in the future. Well, I'm not going to quibble with you about procedural details. But I have to wonder why they're in the document at all. Looks like the IETF wants to publish a proposed standard explicitly designed to break a very popular implementation, with no technical reason. I think that speaks volumes about the IETF, its management, and the quality of its individual contributors. You don't have to listen to the WG, but if one or two WG members are going to deploy and then standardize whatever they've done, that's an informational document. That is not true. If it is a protocol or a format, standards track is also appropriate. Well, I don't want to standardize some of what James has deployed. It won't work in Sean's implementation. I'm not sure I can interoperably implement the parts in question. Your two biggest client implementers aren't real happy about this. It might be appropriate if you really stretch, but it's sure not smart. -- Robert Sayre
Re: Does xml:base apply to type=html content?
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. And perhaps try to obsolete the relevant header if possible... Isn't this something the HTTP WG should be doing? Just for the record, there is currently no HTTP WG. The mailing list of the former HTTP WG still exists. As this was an IETF WG, and is an IETF mailing list (hosted by W3C), you can easily join and bring this issue up. Here's the necessary data: List-Id: ietf-http-wg.w3.org List-Help: http://www.w3.org/Mail/ List-Subscribe: mailto:[EMAIL PROTECTED] Resent-Message-Id: [EMAIL PROTECTED] List-Unsubscribe: mailto:[EMAIL PROTECTED] Resent-Message-Id: [EMAIL PROTECTED] Regards,Martin. I guess so. The HTML WG (W3C, same concept) should be doing a lot of things as well. That doesn't mean it actually happens... -- Anne van Kesteren http://annevankesteren.nl/
Re: Datatype for IRIs in RELAX NG
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 one of the easiest things, but it would be TOTALLY wrong. http://www.w3.org/TR/xmlschema-2/datatypes.html#anyURI says, among else: The mapping from anyURI values to URIs is as defined by the URI reference escaping procedure defined in Section 5.4 Locator Attribute of [XML Linking Language] (see also Section 8 Character Encoding in URI References of [Character Model]). This means that a wide range of internationalized resource identifiers can be specified when an anyURI is called for, and still be understood as URIs per [RFC 2396], as amended by [RFC 2732], where appropriate to identify resources. If there is confusion in other venues about this issue, please help to make sure it gets fixed. Regards,Martin.
Re: Atom syndication schema
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 characters that are not allowed in URIs nor in IRIs (but the IRI spec has an escape hatch for such cases). 2) The IRI spec contains many more details than the xs:anyURI description, in particular also some requirements re. normalization. However, some of the requirements in this area of the IRI spec may be lowered or removed in the future because we have received feedback from implementers that there are difficulties to implement these. I agree with Martin that it would be incorrect to use xsd:anyURI here. Sorry, but I never said that it would be incorrect to use xsd:anyURI. I personally think that it should be okay to use xsd:anyURI. The differences are microscopic, and they should become even smaller, or hopefully go away completely, over time. It does not make sense to perpetuate minor differences for something that was and is supposed to be one and the same thing. Regards,Martin.
Re: Atom syndication schema
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 references can be in attributes and elements of type |anyURI. | So, actually, it seems that the Atom RNC could say atomUri = xs:anyURI. Yes, I think that's the case. Some details (from the primary editor of RFC 3987 :-): From a mile high viewpoint, and even from much lower, it is definitely the case. From the viewpoint of intent, it is also definitely the case. 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 in IRIs (but the IRI spec has an escape hatch for such cases). 2) The IRI spec contains many more details than the xs:anyURI description, in particular also some requirements re. normalization. However, some of the requirements in this area of the IRI spec may be lowered or removed in the future because we have received feedback from implementers that there are difficulties to implement these. Regards,Martin.
Re: Atom syndication schema
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 having xml:lang may be seen as a feature. While these often contain pieces from one language or another, they are not really in a language. Regards, Martin.
Re: ACE - Atom Common Extensions Namespace
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 that it would likely change to something better. Good. I wanted to comment that I don't like ACE because the term is also used in the context of Internationalized Domain Names (where it stands for ASCII-compatible encoding). Regards,Martin.
Re: ACE - Atom Common Extensions Namespace
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 files, only names. Yes. But the W3C insists on having an actual file there, just for documentation at least, or ideally for some machine-readable information (schema,...). Also, some filesystem implementations do allow a file and a folder with the same name. Yes. The W3C server could certainly be tweaked to allow that, but it would be easier not to have to do that. Regards, Martin.
Re: If you want Fat Pings just use Atom!
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 won't be able to keep signatures for entries originally published in an encoding other than the one you've chosen. Wrong, unfortunately. XML Signature requires to transcode to UTF-8 before signing, exactly to protect against such problems. If one were to want to signal an encoding change mid-stream, how might that work with what's been proposed thus far? You can't change an encoding midstream in an XML entity. You can use different encodings for different external entities, though. Regrads, Martin.
Re: If you want Fat Pings just use Atom!
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 story. No need to keep state or look for patterns or anything else. Well, modulo character encoding issues, that is. An FF will look differently in UTF-16 than in ASCII-based encodings. Regards, Martin.
Re: Major backtracking on canonicalization
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 from whatever encoding your document or fragment is, so essentially, we are signing characters, not bits. Regards,Martin.
Re: Clearing a discuss vote on the Atom format
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 changes looked reasonable, but the MUST above looks too strong to me. What about something like Atom Processors that sign Atom Documents MUST support the use of Canonical XML. or even Atom Processors that sign Atom Documents MUST use Canonical XML by default; they MAY use other canonicalizations at user request. The reason for this is to make sure we have interoperability with a mandatory-to-implement (and default-to-use) canonicalization, but that we don't disallow other canonicalizations that for one or the other as of now not yet clear reason may be preferable in some cases in the future (but in your wording would prohibit the result to be called Atom at all). Regards, Martin.
Re: IESG defers discussion of the format document for two weeks
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... https://datatracker.ietf.org/public/pidtracker.cgi? command=view_commentid= 36536 https://datatracker.ietf.org/public/pidtracker.cgi? command=view_commentid= 36539 Nope, these are non-controversial editorial improvements Mostly, yes. which need not slow us down, they can go into that last draft that we'd have to do anyhow to fix the errors that have been turned up and put in the contributors and so on. Specifically, they want us to make it clearer that yes, we do have two similar-looking instances of type= with different rules, and to make it clear that to dereference a IRI you have to turn it into a URI. The person who put the defer on didn't raise these issues. -Tim Some care (and some headstart) is nonetheless helpful. Ted at https://datatracker.ietf.org/public/pidtracker.cgi?command=view_commentid=36539 says This is true for any scheme which does not support IRIs natively. This is slightly inaccurate; schemes are irrelevant here, it's protocols that count (which is the word used in most of the rest of the text). Regards,Martin.
Re: Question on Use Case: Choosing atom:content's type when ArchivingMailing Lists
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 to be that conversion to HTML is good for human consumption with a browser, and for human navigation in an archive. message/rfc822 is the original, and may be very good for reuse in a mailer (e.g. for replying), except that mailers don't support it much at the moment. atom:content type=message/rfc822 src=http://www.example.org/lists/list/archive/12345/ looks perfectly okay to me if that's what you want to do. The average atom software may have difficulties treating the message in a good way, but special applications could do very interesting things with it. If the spec prohibits it, that should maybe be fixed in the long term. To show that there are good uses for it, and working implementations, is the best start in that direction. Regards,Martin. At 10:19 05/06/09, Andreas Sewe wrote: I have a question regarding a specific Atom use case: What is the preferred way to set up an Atom feed listing the contents of a mailing list's archive, given that composite media types (in particular message/rfc822) are disallowed for atom:content's type attribute? This prevents me from doing something like the following, serving the archived mails as-is via HTTP: atom:content type=message/rfc822 src=http://www.example.org/lists/list/archive/12345/ But then again there might be something more fundamentally wrong with serving mails as message/rfc822 via HTTP than I currently realize -- and I should better serve the mails as text/plain or convert them to HTML first (which is the way the atom-syntax archive works). Nevertheless, any advice on this issue would be greatly appreciated. Regards, Andreas Sewe
Re: 4.2.7.1 Comparing atom:id
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 to select (or avoid) a network action, such as retrieval of a representation, fragment components (if any) should be excluded from the comparison. IDs are just identifiers, not used for network action, so this doesn't apply. Regards,Martin. Are we going to refer to that specification and that section from 4.2.7.1 in a future draft? -- Anne van Kesteren http://annevankesteren.nl/
Re: Deterministic content models (conflict with Atom Publishing Protocol?)
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 models. Will the APP limit Atom entries in SOAP envelopes content model to fit WSDL/XML Schema constraints (actually, the APP will already need to limit Atom entries to have a mandatory atom:content I think)? Or should the Atom Syndication Format use deterministic content models to allow XML Schema, thus such uses as WSDL for Web Services? Are you speaking about potential non-determinism or actual non-determinism? Is such non-determinism in the core of the Atom format, in potential extensions, or in payloads (e.g. XHTML,...)? If there is actual non-determinism now in the Atom core, that would be a reason for concern. If there is potential non-determinism in the payloads or extensions, it should be possible to handle that by a more open content model in XML Schema. Regards,Martin.
Re: Compulsory feed ID?
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 to say this). Please indicate agreement or disagreement with this proposition in the next day or two. wth, +1 +1 here too.Regards, Martin.
Re: PaceOptionalXhtmlDiv
(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, it would be much easier to (Bmake optional (otherwise we get into the discussion of whether it's (Ba wrapper div or a real div. Also, it would make things clearer to (Bpeople who read the source but not the spec. Other names would of (Bcourse be fine, I don't particularly care about a specific one. (B (BSo we would have any of the following: (B (BA) No wrapper, none needed, because default namespace set outside (B (Batom:summary type="xhtml" (B xmlns:atom="...Atom NS..." (B xmlns="...XHTML NS..." (BThis is one busted-ass document - emyow!/em. (B/atom:summary (B (BB) No wrapper, none needed, because XHTML has prefix (B (Batom:summary type="xhtml" (B xmlns:atom="...Atom NS..." (B xmlns:html="...XHTML NS..." (BThis is one busted-ass document - html:emyow!/html:em. (B/atom:summary (B (BC) With wrapper (B (Bsummary type="xhtml" (B xmlns="...Atom NS..." (Bwrapper xmlns="...XHTML NS..." (BThis is one busted-ass document - emyow!/em. (B/wrapper (B/summary (B (BIf there is some support, I'll write a pace. (B (BRegards,Martin. (B (B (B (BAt 01:36 05/05/15, Bill de h$B%b(Bra wrote: (B (B -1 to PaceOptionalXhtmlDiv. (B (B If we are dealing with systems where a div wrapper is deemed neccessary, (Bthen you want to take steps to miminise people's options. (B (B For example, PaceOptionalXhtmlDiv will help this to occur: (B (B summary type="xhtml" (B xmlns:atom="...Atom NS..." (B xmlns="...XHTML NS..." (BThis is one busted-ass document - emyow!/em. (B /summary (B (B If you can't trust people not to need the div, then you can't make it (Boptional. I unfortunately have a good amount of experience dealing with (Bthis kind of thing outside Atompub. The simplest answer is to stop the (B'envelope' from using a default namespace (don't bother to debate this with (Bme, it's not an imo). We're not doing that with Atom. Failing that, the (Bnext thing consideration is to add/enforce a protective scoping barrier (Bbetween the envelope and the content. We are doing that with Atom. (B (B [I disagree with Graham btw, and would say xhtml:div is actually fighting (Bkluges with kluges, but it works more or less as specified.]
Re: extensions -- Atom NS and unprefixed attributes
Hello Paul, Many thanks for the citations below, this is extremely clear. Going back to the original question/pace that you gave a -1, would that change if in the text IETF Consensus was replaced with IESG Approval? Regards, Martin. At 10:56 05/05/11, Paul Hoffman wrote: At 4:15 PM +0900 5/10/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 that the request be documented in an RFC (though the IESG has discretion to request documents or other supporting materials on a case-by-case basis). IETF Consensus - New values are assigned through the IETF consensus process. Specifically, new assignments are made via RFCs approved by the IESG. Typically, the IESG will seek input on prospective assignments from appropriate persons (e.g., a relevant Working Group if one exists). --Paul Hoffman, Director --Internet Mail Consortium
Re: the atom:copyright element
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 'atom:rights' would be better than the (current) element name 'atom:copyright'. +1 +1 here too.Regards, Martin.
Re: extensions -- Atom NS and unprefixed attributes
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 what would that be? Or would we say that because the atom namespace appears in an IETF spec, it's obvious that only the IETF (thus ultimately the IESG) can add stuff, but we don't have to say so? Regards, Martin. At 11:57 05/05/10, Paul Hoffman wrote: At 7:22 PM -0700 5/9/05, Tim Bray wrote: On May 9, 2005, at 6:52 PM, Robert Sayre wrote: I think we should be clearer that new elements in the Atom namespace and unprefixed attributes with parent elements in the Atom namespace can only be added by IETF consensus. Thoughts? I wonder if there's some standard IETF practice when you define a language as regards future change control? No. Nearly every protocol tries to go its own way. It's a mess. Generally -1. This spec defines what Atom 1.0 is, why try to micro-manage the future? -Tim Agree on the -1. At 10:34 PM -0400 5/9/05, Robert Sayre wrote: Fair enough. But can just anyone add stuff to the Atom namespace? If the IESG lets them, yes. We gotta trust the IESG after the WG shuts down. Fortunately, they have earned that trust over time. --Paul Hoffman, Director --Internet Mail Consortium
RE: PaceAllowDuplicateIDs
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 entries. An abstract entry is made concrete in entry documents or entry elements. An abstract entry may change over time and may have one or more concrete instantiations. Some applications are only interested in being exposed to those concrete entries that reflect the current or most recent state of the abstract entries -- these apps would prefer to see no duplicate ids in concrete feed documents even though these duplicates *will* occur in the abstract feed. Other applications will require visibility to the entire stream of changes to abstract entries -- these applications will wish to see concrete feeds that may contain multiple, differing concrete instantiations of abstract entries. i.e. they will want the concrete feed to be an accurate representation of the abstract feed. Two needs, to views... You say 'some applications' and 'other applications', as if they were on the same footing. In my view, the 'some applicaitons' (only interested in latest version) should be the usual case, and the 'other applications' (interested in more than one version) should be the exception. Mapping that back to the origin, applications generating feeds that in one way or another rely on the user getting more than one, or more than the latest, versions of their entries have made a design error, they have taken the wrong thing for the 'entry'. If they think that they have two different kinds of audiences, interested in two different things, they should publish two feeds. Some people claim that we need a definition for 'entry' to finish this discussion, but once we confirm that a feed can only contain one version of an entry with the same ID, the definition of entry is as clear as we need it to be. This is just the same as for Web pages. If somebody puts up a Web page for the current weather, there is nothing in HTTP that will help me get the past versions of this page. If the publisher thinks that people may be interested in past weather info, they will make up separate pages. If we think that it would be valuable to be able to correlate the entries in both feeds, we should define an extension for that, not mess around with the basic model. An extension would be rather easy, we only need two rel values for links in entries. One rel value could be called permaentry, the other could be called updatingentry. Maybe a third called updatingfeed, if there is an updating feed for a single changing entry. I'm sure there are better names. The main use I see for documents with multiple entries with the same ID is archives. Everything else can be handled by the creater doing the right thing, or by an immediary offering a new feed with versions of the entry (no guarantee to have all of them, in that case). Even archives could be handled that way if really needed, but it's difficult to immagine that everybody will publish an archive feed. We can easily define an archive top level element, and that problem is solved. For aggregators, wanting to forward two or more entries with the same ID for me means that they are simply not doing their job. Aggregators should aggregate, not just function as GIGO (garbage in, garbage out) processors. So it should be clear that I'm -1 on PaceAllowDuplicateIDs. Regards,Martin.
Re: PaceOptionalFeedLink
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 enough. -Tim +1 here, too, since long ago. 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 Well, yes, but how much work can that possibly be? Regards,Martin.
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
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 Processors MAY collapse white-space (including line-breaks), Ok, maybe it is just me, but what does it mean to collapse white-space? Does this mean to replace FWS (in RFC 2822 sense) with a single space? Making this more precise is definitely desirable. But there is also an i18n issue: This works fine for languages that use spaces between words. It doesn't work for languages that don't have spaces between words (Chinese, Japanese, Thai,...). If Text elements are only used for short things such as names or titles, that's not a big issue, the text in question can just be put on a single line. However, when the texts in question are long, it's a serious issue, and should be fixed. My understanding of type=text is that this is just text without any formatting. That's my understanding, too. Hence, it is not meant to be preformatted text such as text/plain or inside an (X)HTML pre. Yes. But that's exactly where the spacing problems with Chinese/Japanese/Thai are. There are no such problems for preformatted text, because the line breaking in the source (as sent) is the same as the line breaking when displayed. For free-flowing text, however, the line breaks in the source and those in the display are not (necessarily) the same, and so linebreaks have to be changed to spaces for Western languages, but to nothing for Chinese/Japanese (and most possibly to a zero-width non-breaking space for Thai), and the spec has to say something about this. Regards,Martin. This means type=text content is a single paragraph of text. If you need paragraphs, lists or any other structural formatting, you have to use type=html or type=xhtml with the appropriate content. I was about to writing a Pace about white-space handling in type=text (either using xml:space or an attribute that would have mimic'd the white-space CSS property) when I understood/recalled that Text Constructs have accessibility in mind (hence their limitation to textual contents) and preformatted text is not accessible enough. -- Thomas Broyer
Re: Last Call: 'The Atom Syndication Format' to Proposed Standard
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 humans in a readable fashion. Thus, Atom Processors MAY collapse white-space (including line-breaks), Ok, maybe it is just me, but what does it mean to collapse white-space? Does this mean to replace FWS (in RFC 2822 sense) with a single space? Making this more precise is definitely desirable. But there is also an i18n issue: This works fine for languages that use spaces between words. It doesn't work for languages that don't have spaces between words (Chinese, Japanese, Thai,...). If Text elements are only used for short things such as names or titles, that's not a big issue, the text in question can just be put on a single line. However, when the texts in question are long, it's a serious issue, and should be fixed. and display the text using typographic techniques such as justification and proportional fonts. 4.1.3.3 Processing Model ... 2. If the value of type is html, the content of atom:content MUST NOT contain child elements, and SHOULD be suitable for handling as HTML [HTML]. The HTML markup must be escaped; for Should the must be changed to MUST here? Yes, please! 6.3 Software Processing of Foreign Markup ... When unknown foreign markup is encountered in a Text Contruct or atom:content element, software SHOULD ignore the markup and process any text content of foreign elements as though the surrounding markup were not present. I reread this paragraph few times and I am still not quite sure what the paragraph is trying to say. Is it trying to say if the content of a foreign element looks like XML with unrecognized schema - just strip the markup and process the text? Reading this, I got confused because we have both Text Construct and Text as subtitles. I suggest to change the subtitle Text to something like Text Construct with type='text' or so. Also, starting a section with just an example looks weird. Please add an introductory sentence. Same of course for the parallel subsections. Regards,Martin.
Re: IRI/URI
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, but if it is considered to be an IRI it will point to a different location than if it is considered to be a URI. Sorry, wrong. No need to worry. IRI (as URI): http://example.com/200%2525equalsZero Wrong. Please check section 3.1 of RFC 3987 again. At the start of Step 2, it says: For each character in 'ucschar' or 'iprivate', apply steps 2.1 through 2.3 below. The % character is neither part of 'ucschar' nor of 'iprivate', so it doesn't get escaped when converting from an IRI to an URI. Regards,Martin. URI: http://example.com/200%25equalsZero Reading through the draft, it seems like IRIs might be the only thing allowed. If so, could this be made clearer - through a renaming of the element for instance I'm not sure if this is even a problem, perhaps there's something I've missed in the stack of protocols sitting out there. Feel free to castrate me if this is the case, I've gotten myself rather confused trying to work through this by myself and thought I'd ask some more knowledgeable people ;)
Re: HTML/XHTML type issues, was: FW: XML Directorate Reviewer Comments
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: Re: [xml-dir] FW: draft-ietf-atompub-format-07.txt is ready for IETF last call ... 2) Section 4.1.3.3 Item 2 The text: for example, br as lt;br. Is this right? Should it be: for example, br as lt;brgt;. We don't need to escape the in text content, as far as I can tell. Correct. From http://www.w3.org/TR/REC-xml/#syntax: The right angle bracket () MAY be represented using the string gt;, and MUST, for compatibility, be escaped using either gt; or a character reference when it appears in the string ]] in content, when that string is not marking the end of a CDATA section. I'm slightly surprised to get such a comment from the XML Directorate. But I guess their main job isn't to check lowly syntax details. Are you suggesting to escape it anyway for consistency/readability? Wouldn't be more readable, in my eyes. I'd like to remind us of another related issue raised a few days ago (http://www.imc.org/atom-syntax/mail-archive/msg14045.html). XHTML content is currently restricted to XHTML Basic (see http://atompub.org/2005/04/04/draft-ietf-atompub-format-07.html#rfc.section.4.1.3.3, http://www.w3.org/TR/xhtml-basic/). As far as I can tell, this means *no styling*: - http://www.w3.org/TR/xhtml-basic/#s1.3.1: style attribute not supported (but class is), but I'd propose to go back to XHTML 1.0 Strict instead. Very good point. A very strong +1. Regards,Martin.
Re: atom:source interactions with xml:base/xml:lang
+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 particularly bad. Should we add some notes to the spec to remind people how to correctly handle base and lang when atom:source-ifying entries? A couple of the complexities are: 1) An @xml:base attribute declared on an entry might be relative to the original feed's URI, or to @xml:base attributes on parent elements. These need to be resolved before they can be copied across into a second feed. 2) The source feed will have atom:entry as a child of atom:feed, but the second feed will have atom:source as a child of atom:entry. This switch in the hierarchy means that if the source feed contains an @xml:lang tag on its entry, but not on its feed, you need to undeclare @xml:lang on atom:source. Likewise, any @xml:base on atom:entry need to be resolved because it can no longer be relative to the base of the atom:feed element. Eg: atom:feed atom:titleSource feed/atom:title ... atom:entry xml:lang=de atom:titleGuten Tag/atom:title ... /atom:entry atom:feed needs to be embedded as: atom:feed atom:titleSecond feed/atom:title ... atom:entry xml:lang=de atom:source xml:lang= atom:titleSource feed/atom:title ... /atom:source atom:titleGuten Tag/atom:title ... /atom:entry atom:feed -- Dave
Re: PaceFeedIdOrSelf
+1 At 02:59 05/04/05, Antone Roundy wrote: http://www.intertwingly.net/wiki/pie/PaceFeedIdOrSelf
Re: Why is alternate link a MUST?
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 make sense to put in some something misleading if an alternate does not exist. I recently sought out and joined this list precisely because I wanted to see if this issue had been addressed. I don't think it's reasonable to assume there will always be an alternate version of a feed. If this remains a MUST, I have no choice but to honor this by using a dummy value for an alternate page, since I may not have an alternate. Without any background, it seems to me that the goal here is to require a link *back* to an HTML page that is presumed to have provided an alternate link to this Atom resource. This of course assumes that an HTML or non-Atom version actually exists, and that resource is independent of the Atom resource. (Consider that I may have an HTML version, but it could be derived from the Atom version using XSLT. It's not accurate to consider this an alternate when it's an XML style sheet involved.) I couldn't find any reference to this issue in the mailing list, aside from this (thankfully recent) thread. If it's been addressed before, could someone point me to the thread in the list archives? David -- == David Nesting WL7RO Fastolfe [EMAIL PROTECTED] http://fastolfe.net/ == fastolfe.net/me/pgp-key A054 47B1 6D4C E97A D882 C41F 3065 57D9 832F AB01
Re: s/url/web/
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 opinion is currently about as follows: [wrap up and ship:+1] ref/href: +0.8 uri, iri: +0.5 at, about: +0.2 web, internet: +- 0 url: -0.2 (outdated) Regards,Martin. At 03:42 05/03/19, Dan Brickley wrote: * Bjoern Hoehrmann [EMAIL PROTECTED] [2005-03-18 19:31+0100] * 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 resources, are identified by global identifiers called Uniform Resource Identifiers (URI). ]] Let's ignore that not all IRIs are URIs and let's assume that this is a definition of Web, are you saying that this definition is equivalent to 'the set of all URIs is the information space Web'? If those are not equivalent I am not sure what you are suggesting here. The definition says, in effect, The Web is an information space in which we use URIs when identifying things. It does not rule out other, complementary, identification mechanisms, nor does it equate the Web with any specific set of entities. It is an over-arching abstraction, not a set of URI-named things, nor the set of URIs. I guess it is (and I cringe at the word), a bit like cyberspace. Nobody really expects there to be real answers to how many things are 'in' cyberspace?, since that is over-stretching the metaphor. Same with Web, I think. Dan
Re: IRI references to images
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 [RFC3987] which identifies an image which provides iconic visual identification for a feed The atom:image element's content is an IRI [RFC3987] which identifies an image which provides visual identific I think these should both be IRI references, not IRIs. -- Dave
Re: Attributes on the xhtml:div wrapper
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 why they wouldn't be able to handle xml:lang on xhtml:div. Regards,Martin. At 14:46 05/03/17, Antone Roundy wrote: On Wednesday, March 16, 2005, at 03:57 PM, David Powell wrote: Should we: a) keep the current text. b) disallow attributes on the xhtml:div wrapper. c) disallow XHTML attributes on the xhtml:div wrapper, but allow xml:lang. I vote for b). Allowing xml:lang on xhtml:div is unnecessary because it can be placed on the content construct itself with the same effect. Allowing attributes on a wrapper element which most people would otherwise just throw away adds unnecessary complexity and surprise. I imagine this is what you meant by b), but just to be sure, I'd vote for d) disallow attributes other than namespace declarations on the xhtml:div wrapper.
Re: Back on type=HTML, going a step farther...
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 don't have community consensus in favor of XHTML, even though it's obviously cleaner. -Tim I really hope they don't take an opaque chunk of bytes, because if they do, they'll have no clue about the character encoding. Regards,Martin.
Re: Back on type=HTML, going a step farther...
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 consensus for that, which is really disappointing considering the expectations I had 18 months ago :-( I made an even more modest request, namely to put XHTML ahead of HTML in the spec. I still hope we can at least get consensus on that. Regards, Martin.
Re: Back on type=HTML, going a step farther...
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 rather just take an opaque chunk of bytes. I really hope they don't take an opaque chunk of bytes, because if they do, they'll have no clue about the character encoding. Not true; if you can parse the XML to find the atom:content then you know the character encoding and can tell your HTML renderer. -Tim I think Martin was talking about the producer: if all he has is a chunk of *bytes*, there's no reliable way top put that into an HTML-typed text construct (you'll need characters, not bytes). It works both ways. If all you get is a chunk of bytes, things won't work. Of course the Atom processor knows more, but Tim didn't say that it would pass that info on to the renderer. Regards, Martin.
Re: AtomPubIssuesList for 2005/02/22
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, Will there be a two-week WG last call for the Atom format document, as usual with IETF WGs? Regards,Martin.
Re: link rel=link type=????/
(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 the entries. The idea has been to make it easier (Bfor people to build applications that exploit these links and to avoid (Bforcing clients to parse the full source entries. (B (BSo, we$BCW(Be started adding these $BEM(Binks to URIs$BG(Bto the entries we publish (Bon an experimental basis. In order to keep things as simple as possible, (Bwhat we$BCW(Be done is simply use the atom link/ element. We$BCS(Be using rel=$BGM(B (Bink$BG(Bto indicate that this is just a random link of unknown purpose or (Bintent. However, atom requires that a link element have a mime-type. Given (Bthat we have no idea what the mime-type for the URI is, what mime-type (Bshould we use? (B (BAre you talking about the type attribute (as Sam and others have (Bpointed out, that's no longer required) or the rel attribute. (BThe text seems to indicate the former, the examples the later. (B (BPlease clarify. (B (BRegards,Martin. (B (B (B (BSome examples of links that we$BCW(Be published in the last few minutes follow: (B (Blink rel="link" (Bhref="http://news.bbc.co.uk/go/click/rss/0.91/public/-/1/hi/world/middle_east/4286129.st"/ (Blink rel="link" href="http://www.nytimes.com/2005/02/22/politics/22memo.html"/ (Blink rel="link" (Bhref="http://www.washingtonpost.com/wp-dyn/articles/A43009-2005Feb22.html"/ (Blink rel="link" (Bhref="http://www.nytimes.com/2005/02/22/books/22thompson.html"/ (Blink rel="link" href="http://imdb.com/name/nm0588766/"/ (Blink rel="link" (Bhref="http://www.denverpost.com/Stories/0,1413,36~78~2723673,00.html"/ (B (BFor an example feed that contains entries that link to the New York Times, see: (Bhttp://atom.pubsub.com/32/6c/1bc36c085cdc9ecd23efa73a.xmlhttp://atom.pubsub.com/32/6c/1bc36c085cdc9ecd23efa73a.xml (B (BIs there a better $BES(Bel$BG(Bvalue then $BEM(Bink$BG (B What mime-type should we be (Busing? Is there a better way to accomplish what we$BCS(Be doing? (B (BYour comments would be appreciated. If we$BCW(Be done something completely (Binsane here, please be gentle. (B (B bob wyman (B
Re: On PaceXhtmlNamespaceDiv
(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 (Bis eliminated when you stop using defaults (but there are other (Bconsiderations which keep string concat fragile). Use of div covers off the (BXHTML case. (B Yes, use of div covers that case. But that doesn't mean that if (B some people want to use div, everybody has to use div. (B (B It does (I've never said otherwise) - there is a div tax. (B (BI'm okay with those paying div tax who think they need a div. (BI'm not okay with everybody paying div tax for no apparent (Bgeneral benefit. (B (BRegards,Martin.
Re: On PaceXhtmlNamespaceDiv
(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 is following the specs. (B (B The point I'm seeing here is that creating markup using string concats is (Binherently fragile. No surpise there. Wrt namespaces, fragility is (Beliminated when you stop using defaults (but there are other (Bconsiderations which keep string concat fragile). Use of div covers off the (BXHTML case. (B (BYes, use of div covers that case. But that doesn't mean that if (Bsome people want to use div, everybody has to use div. (B (BRegards,Martin.
Re: PaceXhtmlNamespaceDiv
(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 important to make sure that correct namespace declarations (B for XHTML are present. One way to do this is by using an xhtml:div (B element as the content of the atom:content element and specifying (B the XHTML namespace on that div element. Here are some examples: (B ... [use proposed examples] (B There are other ways to declare the namespace URI for XHTML content; (B this specification does not limit the placement of such declarations (B in any way." (B (B My issue with that wording is that it doesn't make it clear whether the (Bxhtml:div that is added is to be considered a part of the content or not. (B (BFair point. (B (B Put another way, how does the consumer know that if a given xhtml:div (Belement is part of the content, or was added per the above? (B (B Julian, you previously said "Let's make the spec as clear and simple as (Bpossible." How about this: (B (Bxhtml:div is required. xhtml:div is not part of the content. (B (B Clear. Simple. And difficult to get wrong. (B (BHow about the following alternative: (B (B xhtml:div is not required. xhtml:div is part of the content. (B (BClear. Simple. And difficult to get wrong :-). (B (BIf that's not enough, we can add a note, e.g.: (B (B Note: A xhtml:div is just an empty wrapper; it will in general (B not affect the processing or display of the content. (B (B (BRegards,Martin.
Re: On PaceXhtmlNamespaceDiv (was: Re: Consensus call on last round ofPaces)
[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: Everybody has to use an XHTML div in every atom content of type XHTML, just to make sure that Sam (any others?) can realize his dream of atom without namespace prefixes. This despite the fact that those that want to avoid any and all namespace prefixes can use a div on their own if they want. As Sam explained, the div in that case would be part of the content. That's true, but while adding a div formally changes the content, it doesn't actually change the content, because div is just a dummy wrapper, in particular if there are no other attributes than the default namespace declaration. On more general terms, I have observed different choices of how different namespaces get put together over the last three if not more years. For the simple case of namespace B in namespace A, a variety of choices, with a variety of reasons, has been proposed. On the outer side (namespace A), the choices range from foreign namespace stuff can be inserted pretty much anywhere where it makes sense, just put it in to we have a 'foreignstuff' element, anything from another namespace has to go in there. On the inner side (namespace B), the choices again range from any B element can be used to only a wrapper element can be used. As an example, SVG tends to high explicity on both sides, for the inner side, see included document fragments (http://www.w3.org/TR/SVG11/conform#ConformingSVGIncludedDocuments), for the outer side, see foreignObject (http://www.w3.org/TR/SVG11/extend#ForeignObjectElement). Most of the motivation for this explicitness in SVG comes from the fact that without being clear on coordinates/placement/size, things won't work. Looking at these cases, it seems to me that what we are doing with div is really thinly motivated (no need for any special information such as coordinates), and is also in a way abusing div, which was created to indicate divisions in HTML documents, not to serve as a throw-away default namespace holder in foreign document formats. Actually, instead of div, we could as well define that we use body, or we could even define that we use something new like wrapper. Because as it turns out, while this element is in the XHTML namespace, it's never part of an XHTML fragment that an XHTML processor would see. At 05:05 05/02/16, Anne van Kesteren wrote: Tim Bray wrote: PaceXhtmlNamespaceDiv This is tough. There are some people who are really against this and who aren't moving. On the other hand, there are way more who are in favor. Reviewing the discussion, the contras are saying that this is sloppy and unnecessary and if it solves a problem, that problem really shouldn't be there, but they don't seem to be saying it's actively harmful. But the people in favor are arguing that this will reduce errors and improve interop. Also, the Pace was changed in midstream. Also, Paul thinks we will get feedback on this from out there in the IETF. I'm not sure I understand this sentence. Does Paul think that we will get feedback in the IETF to put it in anyway, so we better already put it in? Or that we'll get feedback to take that out in the IETF so we can as well leave it in for the moment? Or what? Regards,Martin. DISPOSITION: Borderline, but accepted. I'm still not sure how it would improve interop, especially since the place the namespace can be defined is optional. I do not think those Planet aggregators would handle the following correct for example: atom:entry xmlns:atom=... xmlns:b=http://www.w3.org/1999/xhtml; atom:content type=XHTML b:div Foo b:br / Et cetera. ... Also, this restriction can be avoided by using |type=application/xml| or |type=application/xhtml+xml| I assume? (Although that is probably not valid for the TITLE or SUMMARY element (it should be).) -- Anne van Kesteren http://annevankesteren.nl/
Re: type=HTML
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 have suggested this before. This is very close to editorial, but can already give some hint. The second is to add a sentence such as this: Content producers that can produce both XHTML content and HTML content SHOULD produce XHTML content. Regards,Martin.
Re: PaceXhtmlNamespaceDiv
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) Require an xhtml:div as the only direct child of content of type XHTML 2) Not limit the placement of namespace declarations in any way above and beyond those given in the Namespace spec. 3) Not require any specific namespace prefixes. If 2) and 3) are correct, I can live with this proposal. Anything changing 2) or 3), as may have been previously in this Pace, would get something like a -2 from me. Specs, in particular such fundamental ones as XML Namespaces, are there to be used as is, not to be tweaked. As for 1), I could live with it, but the rationale given for it in the current version says: Given that even we often forget when writing examples to declare the XHTML namespace for XHTML text constructs and content elements, it seems likely that people producing actual feeds will forget to do so unless the requirement to do so is stated prominently and unambiguously. This doesn't seem to match the proposal, where Namespace declarations are only used in the examples, but not mentioned in the text. So while (as said above) I can live with 1), insisting on 1) without a better rationale doesn't seem to make sense to me. If the concern expressed in the rationale is important (and I can agree it is), then addressing this concern can be done in less constricting ways, i.e. by replacing the requirement for a div with something like: Note: It is important to make sure that correct namespace declarations for XHTML are present. One way to do this is by using an xhtml:div element as the content of the atom:content element and specifying the XHTML namespace on that div element. Here are some examples: ... [use proposed examples] There are other ways to declare the namespace URI for XHTML content; this specification does not limit the placement of such declarations in any way. Regards, Martin.
Re: IRIs
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 IRI to a URI, Correct. but it may not be possible to convert a URI back to the same IRI it was generated from. Correct. For example, it is always possible to convert an IRI to ASCII for use in HTTP's Request-URI, but it would be better to leave it in Unicode for editing. Exactly. There's also a large section of the draft that deals with right-to-left IRIs, but I don't understand it. It's not relevant for a protocol, but it is relevant for input and display of IRIs that contain Arabic or Hebrew characters. Regards,Martin.
Re: IRIs (was: Re: Work Queue Rotation #16)
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 majority of the world needs them - inclunding French language). - one way is to use Unicode - another way is to use ToASCII and punycode process (used in IDNs) There is only one IRI spec (RFC 3987). For backwards compatibility, it allows the use of punycode for converting domain-name parts of some URIs. Otherwise, it's just converted to %-encoding using UTF-8, and then the URI spec (RFC 3986) takes over. the punycode process : - is reversible (if it was not, the Domain Name could not be valid). It is reversible up to equivalent domain names, in particular, it does not conserve case, if you take stringprep into account. - is used in IDNs in transcoding the Unicode into ascii for 2LD and above level and in adding the prefix xn--. There is no technical restriction to 2LD and above. There are some people claiming that it should not be used for TLDs, but I would disagree. It works for TLDs as well as for other levels. The difficult problems on the TLD level are political, but those don't go away with a different technical solution. - can obvsiously be used to transcode the TLD of a domain name, but there is no specification in RFCs about TLDs being punycoded. I think rfc 3986 is pretty clear about this, and doesn't make an exception for TLDs. From http://www.ietf.org/rfc/rfc3986.txt: The reg-name syntax allows percent-encoded octets in order to represent non-ASCII registered names in a uniform way that is independent of the underlying name resolution technology. Non-ASCII characters must first be encoded according to UTF-8 [STD63], and then each octet of the corresponding UTF-8 sequence must be percent- encoded to be represented as URI characters. URI producing applications must not use percent-encoding in host unless it is used to represent a UTF-8 character sequence. When a non-ASCII registered name represents an internationalized domain name intended for resolution via the DNS, the name must be transformed to the IDNA encoding [RFC3490] prior to name lookup. URI producers should provide these registered names in the IDNA encoding, rather than a percent-encoding, if they wish to maximize interoperability with legacy URI resolvers. Yet there are ML.ML domain names already in use (both by Govs agencies and in private spaces). These are just rouge local setups, not conforming to any kind of spec. I asked the author of the IRI RFC. He reponded to most of my questions. But the situation of the TLD is not clear as it is not supported by IE, but is supported by plug-in. In this sense, TLDs are no different from other levels of the domain name hierarchy. The case of ATOM is different as not dependent from browsers. It would be a very bad idea if Atom decided to dereference URIs or IRIs in a different way from other software. Also it is likely that in the ATOM definition timeframe the ML.ML (multilingual.multilingual) will most probably broadly in use in some areas of the world. It would be good. There is nothing in IRIs or URIs preventing the use of non-ASCII.non-ASCII domain names (multilingual in this context is totally inappropriate, although a lot of people use it that way). It is up to ICANN to decide on new TLDs, and it's a political problem, not a technical one. Regards, Martin.
Re: Posted PaceTextRules
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 minor nit that lone line breaks should be considered spaces--not disregarded. Thus: Software displaying this text SHOULD remove white-space at the beginning and end; and treat sequences of one or more XML white-space characters as a single space. Except that that's completely inadequate for some Asian languages (Chinese, Japanese, Thai,...). Point to a spec developed by experts if you need to rather than trying to reinvent the wheel. Regards,Martin.
Re: Posted PaceTextRules
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 published. -Tim Would you mind explaining why you think it's wrong? Regards,Martin.
Re: Questions about -04
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. [...] I'm -1 on removing this restriction. I thought we came to a sort of consensus that the link should be optional. Or was that only for atom:entry? Anyway, I think both of them should be optional. That is, I disagree with you, Sam. I agree with Asbjoern. Regards, Martin. There is consensus that atom:link is not required for atom:entries which contain content. That consensus has been reflected in the most recent drafts. That is not the question referred to above. Understood. There are now, by some counts, ten versions of formats that call themselves RSS. Every last one of then has a required channel/link. Every last one of them. Relaxing a restriction requires consumers to handle more cases. How difficult can it possibly be, in this specific case? My expectation is that given limited demand for this feature, the more likely scenario is that consumers will either produce unexpected results or outright fail for feeds without this data. What do they need it for in the first place? Because of this, I would like to request that there be a compelling use case be found which for feeds for which there can not be a atom:link defined. Is there a compelling use case (not it has always been that way, which doesn't count as an use case) for requiring it? The use case for not having it is pretty straightforward: Just a feed. It's that simple. Feeds can live on their own. They don't need alternate Web pages, and if they don't have have them, it's just straightforward design to not require such an element. Everything else is just cheating ourselves. Note atom:link is defined as a URI. While most examples that we have seen use the HTTP scheme, this is not a requirement. Given that this is not a requirement, and given that existing RSS producers have come out in mass demanding that this restriction be lifted from RSS, I can only conclude that the burden seems rather low. So you are saying that atom:feed atom:head atom:link rel=alternate href=noscheme://nonsense.example.org/this/here/to/keep/Sam/happy ... is better than just leaving that link out? Do we want the above nonsense to go into the RDF model, and so on? Isn't it much more straightforward to model the format after actual and potential realities, rather than to have to cheat? Regards,Martin.
Re: Feed State [was: Work Queue Rotation #16]
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 manner in which Atom Feed Documents are combined in order to reconstruct a feed (including methods of identifying duplicate entries, updating metadata, and dealing with missing entries) is out of the scope of this specification, but may be defined by an extension to Atom. ]]] So, if we drop PaceFeedState, I propose the text above. Fine with me, except that I'd change the second parenthesis from: (including methods of identifying duplicate entries, updating metadata, and dealing with missing entries) to: (including methods of updating metadata and dealing with missing entries) How to identify duplicate entries is clear from the description of the id attribute, so I don't think it belongs here. Regards,Martin.
Re: URI canonicalization
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 are an amazing number of things that can be compared differently once you start (the URI/IRI specs, the scheme-specific specs, and Unicode give you a lot of rope), character- by-character comparison is the only way to go. Third, I don't think that the normalization advice in 3.5.1 Dereferencing Identity Constructs is extremely important, but I don't mind if it's there. I have the following actual editing proposals to hopefully make this part of the spec a bit clearer: 1) switch sections 3.5.1 and 3.5.2 to make clear that comparison of IDs is the most important operation. 2) At the start of Comparing Identity Constructs, change the sentence Instances of Identity constructs can be compared to determine whether an entry or feed is the same as one seen before. to To determine whether an entry or feed is the same as one seen before, their Identity Constructs are compared. This makes it clear that we are talking about here is how you do it, rather than here's one way to do it. 3) Change Processors MUST compare Identity constructs on a character-by-character basis in a case-sensitive fashion. to Processors MUST compare Identity constructs on a character-by-character basis. For details, see section 5.3.1., Simple String Comparison, of [RFC3987]. We may want to add something about case-sensitivity as a note, but it should not be in the main text. There are way to many other ways that this could go wrong, in particular in an Unicode context. 4) Add a sentence saying something like Feeds or Entries are identical if their IDs compare identical.. Seems obvious, but isn't stated anywhere. 5) Add a note saying something like Comparison functions provided by many URI classes/implementations make additional assumptions about equality that are not true for Identity Constructs. Atom processors therefore should use simple string functions for comparing Identity Constructs. I think such a note could be a good balance to the normalization advice. I understand that in general, we have tried to reduce implementation advice in the spec as much as possible. But in my experience, adding such advice or notes is often a good way to reach better consensus. Regards,Martin. At 02:17 05/01/31, Graham wrote: This controversial text is still in: Because of the risk of confusion between URIs that would be equivalent if dereferenced, the following normalization strategy is strongly encouraged when generating Identity constructs: o Provide the scheme in lowercase characters. o Provide the host, if any, in lowercase characters. o Only perform percent-encoding where it is essential. o Use uppercase A-through-F characters when percent-encoding. o Prevent dot-segments appearing in paths. o For schemes that define a default authority, use an empty authority if the default is desired. o For schemes that define an empty path to be equivalent to a path of /, use /. o For schemes that define a port, use an empty port if the default is desired. o Preserve empty fragment identifiers and queries. o Ensure that all portions of the URI are UTF-8 encoded NFC form Unicode strings. For starters its in the Dereferecing section for some reason. Secondly, no consensus was reached to include it. Tim shrugged when no proposal gained consensus, and included it anyway. Thirdly, the rationale in the spec doesn't match any of the even-vaguely-valid ones given on the list. Fourthly, none of those rationales were valid. Fifthly, it's micromanaging. Of all the things we could go into great detail telling people how to do, this doesn't even rate. I've never seen a feed that has any of the problems this might solve. Please delete it. Graham
Re: PaceIRI status: RFC 3987 and STD 66, RFC 3986, published
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 instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Yes. That was put in to clearly say that you can't just expect IRIs to work wherever URIs work without doing anything. Because Atom is a new protocol, we are in a very good position to do the right thing, which turns out to be very little. Do you expect Atom implementors will be using incompatible existing software? I think this question should face roughly the same scrutiny that PUT/DELETE did. Yes. If you look at the pace (http://www.intertwingly.net/wiki/pie/PaceIRI, just updated to take into account the RFC publications, most of this is described under Impact. Converting an IRI to UTF-8 and doing %-encoding is a lot easier to program if there is no IRI library available than to program your own PUT or DELETE requests, in particular because the former is a completely internal operation, whereas the later is a network operation. Integrating conversion to punycode in case there is no IDN support available is a bit more work, but if you don't do normalization (stringprep,...), the code footprint should be extremely small. Except for encoding issues (UTF-8 or UTF-16 vs. UTF-32), you can basically just copy the code from http://www.rfc-editor.org/rfc/rfc3492.txt. I'm also worried that the term IRI will cause confusion. After all, the catch phrase is not Cool IRIs Don't Change. What can we do minimize confusion? First, every URI is an IRI, so there is absolutely no need for any existing URI to change. Second, there is the confusion with terms. I agree that the term IRI shouldn't be pushed too much, I expect users e.g. in Japan to just use language like software x-y-z now accepts URLs/Web addresses with Japanese characters. But in the spec, we have to make clear that IRIs are allowed, in a way that implementers actually see it. So that's why I propose to replace the term URI with the term IRI throughout the spec, but not to change the attribute names. But I'm open to discussion about this; if you have some other ideas, please send them to the list. Regards,Martin.
Re: Issues with draft-ietf-atompub-format-04
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 that 'type' != 'type' and conflate the two concepts. Even you made that mistake just now, and you're the editor of the document. Pity the poor reader. Looking at it from a usability of specifications p.o.v., it doesn't hurt to have cross references. I agree this is a problem. Either we find new names for the attributes so that each element has a different attribute, or we put pointers to the other 'type' attribute(s) in each section about a type attribute (and ideally also a table somewhere that shows all of them). If we don't do it, confusion will be guaranteed, and we will know we are the ones to blame. Regards,Martin.
Re: PaceIRI status
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 is definitely not the right term. (for instance, I also think that the introduction into XMLNS 1.1 was a mistake). Well, I might agree that it was a mistake. Observable behavior for most implementations (in particular XSLT implementations, where you most easily can test actual namespace behavior) allows IRIs in namespaces anyway, so this could just have been a clarification to the XMLNS 1.0 spec, rather than bumping up the number. Regards,Martin.
Re: PaceSimpleLanguageTagging status
(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 wrote: (B Not yet taken up by the WG, depends on the discussion that comes with (B this call. Same rules as all the others: there has to be a positive WG (B consensus that each adds to the base specification. -Tim (B (B +1, at least for atom:language inside the header. For elements, well, (B there _are_ use cases for elements in different languages, so, since it is (B optional, +1 again. (B (B -1, or better, -2. Inventing things like atom:language when there (B is xml:lang is just completely useless and superfluous. (B (B Could you clarify how xml:lang solves the problems stated in the Pace? (B The alternatives to the Pace would seem to be either restrict xml:lang (B to specific elements or implementations that lose xml:lang information (B or, in an authoring scenario, do not allow to use it -- i.e., ignoring (B the problem in the specification. Neither of which is really helped by (B xml:lang, so your comment seems a bit weird. (B -- (B Bj$BS(Bn H$BI(Brmann $B%-(B mailto:[EMAIL PROTECTED] $B%-(B http://bjoern.hoehrmann.de (B Weinh. Str. 22 $B%-(B Telefon: +49(0)621/4309674 $B%-(B http://www.bjoernsworld.de (B 68309 Mannheim $B%-(B PGP Pub. KeyID: 0xA4357E78 $B%-(B http://www.websitedev.de/
Re: PaceMustBeWellFormed status
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 well-formedness relies on first determining the character encoding of the XML document. RFC 3023 defines how to determine the character encoding of XML documents served over HTTP. The first sentence is redundant because all Atom feeds must be well-formed. The second sentence is plainly false. The two concepts are unrelated. Could you explain/substantiate your claim that the second sentence is plainly false? I understand it to be true, and I have implementation experience with the W3C Markup Validator to back it up. 5. Publishers MUST NOT serve Atom feeds with a media type other than application/atom+xml (registered in this Section 8 of document) or one of the XML media types defined in RFC 3023 or its successor. In particular, text/plain is never an appropriate media type for an Atom feed. When retrieving an Atom feed served with a non-XML media type, clients MUST reject it as non-well-formed. We have no business stating this. I will serve Atom feeds as text/plain if I want them processed as text documents. At which time I will claim that it's no longer an Atom feed, it just looks like one :-). The Atom spec should talk about Atom as Atom; that somebody might want to look at the Atom document as a text document, or even as a hex dump, isn't something we should be talking about. Regards,Martin.
Re: PaceIRI status
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 devices. Just a correction to what Julian wrote: Stringprep may be ignored or partially ignored, because it requires lots of data, but I don't think the Unicode-punycode conversion will be ignored. I would like to hear more from developers whether or not they think this is a problem. (I'm asking this wearing my co-chair-looking-for-consensus hat, not my author-of-IDN-and-stringprep hat.) Although I don't have any experience with developing blogging tools, I have some experience in integrating IDN support into a browser, and I can report on some other browsers. I hope this breaks the ice for others to chip in. 1) I have integrated IDN support into libwww, and used it in Amaya (that version isn't yet public, but it should be soon). Integrating idnkit into libwww was easy (except for the autoconf/ automake,... files, which I'm leaving to somebody else). idnkit of course includes full stringprep. 2) The maker of a widely used browser for Mobile phones has just recently announced that they support for internationalized domain names at http://www.access.co.jp/english/press/050120.html My guess is that they take some shortcuts on stringprep, but that's really just a guess. If you really need to know, I may be able to ask somebody from that company. 3) Browsers start to integrate blog support. These browsers are at the leading edge of development, and usually support IDNs already. The examples I know are Opera and Safari. IDNs will just work on those browsers, and people will come to expect them to work in other contexts. I think at least at some stage, Opera didn't implement strinprep (or not completely), but I haven't tested lately. Regards, Martin.
Re: Questions about -04
(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 that the link should be optional. (B Or was that only for atom:entry? Anyway, I think both of them should be (B optional. That is, I disagree with you, Sam. (B (BI agree with Asbjoern. Regards, Martin.
Re: PaceIRI status: RFC 3987 and STD 66, RFC 3986, published
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 URI spec, known as RFC2396bis, is now published as STD 66, RFC 3986. Even less reason for not adopting them. Editors, please update your references. I'll update PaceIRI in a day or two. Regards,Martin.
Re: AtomAsRDF_PaceAttributesNS
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 pieces in place, and gets general feedback from the clients. One checks that it works. Then one iteratively works towards a goal of getting something that satisfies the clients needs and budget. But you are correct to demand some real code. I have branched off the particular topic in AtomAsRDF_PaceAttributesNS [1], so that those that only want to work on detailed text, can get going debating and refining that. I would be very thankful if someone with more specification experience could get it into the correct final format. It is not code that Tim is asking for, but merely words. The specification is but a set of paragraphs, and somebody needs to say insert these words there. As to the words that you have proposed, I have a technical question: if you are equating unnamed attributes with attributes in the atom namespace, then everybody who looks today for an href attribute would *also* have to look for an atom:href attribute. Multiply this by all of the attributes defined in the specification, and IMHO, you have a solution that is *worse* than requiring the atom namespace in the first place. So, -1 That's not the way I have understood this. What I thought this to be is: In Atom, these attributes always are unprefixed. They are in the Atom namespace just for the purposes of RDF. From my perspective, Atom can be one XSLT translation away from RDF/XML, and will likely remain such. We can capture that translation as a non-normative appendix to the spec. We can also look at GRDDL or other techniques for making this explicit in the documents. But what I don't want is to make the syntax dramatially worse for people who want to use simple XML processing tools. Agreed. I just saw the text that we would insert into the spec as a verbal description of one aspect (adding an Atom-namespace prefix) of that transformation. But I can see that the current text, Processors should interpret unprefixed attributes in atom namespaced elements to be in the atom namespace, can easily be interpreted the way you have done it. I think this can be fixed by changing it to something like For the purpose of transformation to or interpretation as RDF, unprefixed attributes in atom namespaced elements to be interpreted as being in the atom namespace. I guess that Henry didn't add the clarification because he saw the text in the context of an overall AtomAsRDF section, which would make the context clear enough. Regards,Martin.
Re: Posted PaceSimpleLanguageTagging
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 with an instance of xml:lang on another element within that content. From this text, it is indeed not clear. There is an erratum that makes this clearer. Please see http://www.w3.org/XML/xml-V10-3e-errata#E01. If we allow it to inherit inappropriately, and we restrict it to certain elements, then this makes the situation even worse, as we'll have no way of re-declaring or un-declaring xml:lang on elements that it shouldn't apply to. I don't understand this. If the spec says that it doesn't apply to some element, there is no reason to un-declare it in the content, and of course even less a reason to re-declare it. Please also note that the current version of the XML spec allows xml:lang=, i.e. the empty string as a value to say that you don't have any information about the language. This is handy for cases like 1) the element is natural language text, but the actual content is e.g. only math or some other special notation that doesn't belong to a natural language, and 2) the actual content is natural language text, but the software doesn't know which language it is. As an aside: We should make sure that the Atom spec is very clear for each element that inherits (e.g. copyright,...) how to define the absence of such information. As experiece with xml:lang and other things has shown, having something like a 'reset' or 'neutral element' is extremely important every time there is inheritance, in particular for information that comes from different sources. I think it is very unlikely that a user would want to include a title, summary, and content in a different language. Well, somewhat unlikely, but not impossible. What about e.g. a service in Japan that takes some English feed and just changes the titles to Japanese for quicker browsing by a Japanese audience? If we only allow xml:lang on Text constructs and atom:content, then this means that the user would typically have to include it on titles, summaries, and content separately. Would that be ok? Why have to do that for feeds that are completely or mostly monolingual? Would it be any better than a dc:language style atom:language? Yes. It would still be better. As for RDF's support of xml:lang, there is a very RDF-specific, unfortunate issue that has to be taken into account when converting from atom to RDF/XML: RDF/XML at certain points cuts the inheritance of xml:lang. I didn't realize this - where is it? Ok, here it is: The RDF Graph model doesn't deal with mixed content (such as typical XHTML), but the data model has a special datatype that in RDF/XML is indicated by the rdf:parseType=Literal attribute. The problem is that whenever you use this, RDF/XML requires you to cut language inheritance. From http://www.w3.org/TR/2004/REC-rdf-concepts-20040210/#section-Literals: For text that may contain markup, use typed literals with type rdf:XMLLiteral. If language annotation is required, it must be explicitly included as markup, usually by means of an xml:lang attribute. [XHTML] may be included within RDF in this way. Sometimes, in this latter case, an additional span or div element is needed to carry an xml:lang or lang attribute. What this means in practice for Atom is that if it were not for this, you could just use a DTD to declare a default attribute of rdf:parseType=Literal on things like title. However, this won't work, because if you say entry xml:lang='en' ... titleMy entry title./title ... /entry which will look to a parser like entry xml:lang='en' ... title rdf:parseType=LiteralMy entry title./title ... /entry The XML Literal won't carry the language information. Even if you put the language information right on title, as so: entry ... title xml:lang='en' rdf:parseType=LiteralMy entry title./title ... /entry it still isn't picked up by RDF/XML. What RDF/XML requires you to do is something like entry xml:lang='en' ... title rdf:parseType=Literalspan xml:lang='en'My entry title./span/title ... /entry i.e. in order to give the language information to the title in RDF/XML, you have to introduce a 'dummy' element. This means that the simple DTD approach won't work, but such a transform of course can be done by XSLT. It also means that Henry and friends have some more work to define how Atom converts/relates to RDF, because they have to define when/how to introduce dummy elements. Regards, Martin.
Re: Posted PaceSimpleLanguageTagging
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 situations where somebody like him may want to do that. It isn't clear what xml:lang should apply to? Does it apply to email addresses? Aural browsers might use it as a pronunciation hint. So does a database implementation need an email_lang column in the table or not? I think we need to decide on these issues rather than leave it to implementors to guess. I think spelling out in the spec which elements take xml:lang and which ones don't, and which attributes it applies to and which not, would help. Anybody wants to start a list? Regards,Martin.
Re: Content datatypes in XSD?
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 screw things up? It's not 'pretty much anything', it's a Mime media type. This can easily be defined with an XML Schema pattern. The TEXT | HTML | XHTML can also be made part of that pattern, or can be defined as an enumeration type and unioned with the media type pattern. Regards,Martin. Cheers, Danny. 5.12.1 type attribute atom:content MAY have a type attribute, When present, the value MAY be one of TEXT, HTML, or XHTML. Failing that, it MUST be a MIME media type [RFC2045] in which, to use the terminology of Section 5 of [RFC2045], the top level is a discrete type. If the type attribute is not provided, software MUST behave as though it were present with a value of TEXT. -- http://dannyayers.com
Re: Posted PaceSimpleLanguageTagging
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 no meaning if used. It is the inheritance which I have the biggest problem with. Why? It seems silly to mark each and every entry (or even worse, each and every title and content) in a feed as xml:lang=en if most or all of them are in English. We have other things that get inherited from the feed to the entries, so I don't see why this one would be such a problem. Regards,Martin.
Re: Questions about -04
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 above mail thread for having the restriction. And I think that in a very fundamental way, it's a mistake; feeds should be architected as independent technology, not as an adjunct to Web pages. For example, there is no restriction that every Web page has an email address (although such an address was on many Web pages (that was before spam)). Likewise, there is no restriction that every email or Web page point to a feed. Or that every chat channel has an associated feed or Web page. Integration of these communication media is extremely important, but forcing a link is not the right way to go. Regards,Martin.
Re: PaceIRI
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 this might be a problem on small devices, but I would suspect that a proportion of big-device implementors might be tempted to skip this step (if they're anything like me, largely through ignorance of IRIs/IDNs in general). Is there any way of reducing the impact here? Any deployment experience from other application domains that can be drawn on? An IDN library consists of two parts: Nameprep, which is the part needing the big tables, and punycode encoding, which is the encoding/ compression algorithm that is quite compact. My understanding is that indeed some implementers are taking shortcuts with nameprep, although they are definitely not supposed to do so according to the specs. (One possibility where this would be possible even while strictly conforming is for IRIs directly input on a mobile device, where the manufacturer knows what characters can be input and can guarantee that these don't cause problems with nameprep.) Regards,Martin.
PaceIRI
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, the main objection on previous discussions of IRIs was that the IRI spec was not yet approved. But it is approved now. If there are other objections, please say so. Regards, Martin.
content for text/ or +xml SHOULD be local? (was: Re: Hash for Links)
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 that describes the bad things that could happen when people ignore that recommendation, I would be happy to include it. When I read this, I was somewhat surprised to find a SHOULD. A should, in IETF terms, is really quite strong. I'd prefer a wording such as: In general, content with value of type beginning with text/ or ending with +xml will be inline; that is to say, no src attribute is provided. (and I think inline is the better term; local implies on the user's machine rather than inside the document) In both cases, adding something like Such content is usually short, and in that case, carrying it inline is more efficient. covers the rationale I know about. There may be other rationales. Regards, Martin.
Re: PaceIRI
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 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, the main objection on previous discussions of IRIs was that the IRI spec was not yet approved. But it is approved now. If there are other objections, please say so. Regards, Martin.
