On Tue, May 24, 2005 at 01:54:20PM -0400, Karl Dubost wrote: > >The implication (and I think it's pretty clear, but perhaps I'm used > > Implication :) You just name it and that's the source of loooong > (endless) discussions when specs are released.
As I said, I'm probably more used to IETF-style specifications than not. Personally I find them more useful than many W3C documents, but of course, not everyone is used to the IETF style :-) > >>What is a conformant Atom Authoring Tool? > > > >The term "Atom Authoring Tool" isn't in the draft, and it doesn't > >need to be. > > why? I don't think we need to define every possible way in which software can act upon documents in one of the Atom formats. They're documents, so there are two /main/ roles: software that produces the documents, and software that consumes the documents. (Any software may do both, of course.) The specification tells us what is a legal Feed Document, and what is a legal Entry Document (but see following paragraph), and we're not making any additional restrictions on something that produces Atom documents. However we need to discuss how things that /consume/ Atom documents work, because we need to tell them (for instance) how to compare atom:id instances, and note that there are potential security considerations in handling URIs and IRIs. You have an issue with the clarity of how legal Feed/Entry Documents are defined by the spec, but that's actually orthogonal to defining all the possible software actions on these documents - which is why I'm certain we can have a completely clear specification without lots of role definitions. You want the specification to be more explicit. I'm happy without the extra verbiage, because my way of reading the existing document allows me to figure these things out without having to read too much. (It's a bit like that bit in patents which says "this patent also covers derived stuff that is obvious to people versed in the field" - with a document specifying the format, I can infer the existence of different types of software acting in different roles on Atom Feed Documents and Atom Entry Documents.) Having said that, I'm not averse to having a small amount of text defining an Atom Producer as something that creates Feed/Entry Documents in accordance with the spec. > >> It means that all XSLTs, Web hosting > >>services, etc can NOT claim conformance to Atom. :) > > > >Yes they can. > > no for the reason I gave and no because there's no way to claim > conformance to the spec. The reason you gave is that we don't define conformance, but we do. The start of 1.2 says quite clearly: "this specification describes conformance in terms of two artifacts ...", and then goes on to say what those artifacts consist of. I read this as saying, quite clearly, "here are our definitions of two artifacts: obey the rules in this document and you'll be working in the world of comforming Atom documents". I think the argument (discussion? :-) here is just between two different styles of trying to get the same information across. This one has been around a long time, and seems terse yet clear enough to me. I hope I'm not misrepresenting you when I say that your main concern is that this style isn't sufficient. > They are plenty marketing department which will claim conformance to > something even if they have a bad support of it :) Which has after > implications in the world of markets, business offering and > certifications which leads to quagmires. Do we have an example of a spec in the Atom/IETF style that has caused such problems, and of ones in the W3C (conformance level) style that haven't? Marketing departments, unfortunately, will make claims no matter what we write in the final RFC. > >They just can't claim to be Atom Processors unless they > >abide by the rules for Atom Processors (and abide by any definition of > >Atom Processors). > > There's none. We have a number of MUST restrictions on Atom Processors, for instance. > >Something that produces an XML document that abides > >by every normative part of the Atom spec (including honouring every > >MUST clause) that applies to Atom Feed Documents can be considered > >something that 'conforms' to the Atom spec for producing such a > >document. > > Conformity of a document is not conformity of a product. Two > different classes of products. I don't think that's a helpful line of reasoning, but I'm having difficulty expressing why. I understand what you're on about, but consider this: "A JamesGram is a textual representation of the letters 'J', 'a', 'm', 'e', 's', using a character encoding of your choice." >From this, I can tell you that software that says "JamesGram arrived!" when it finds the text "Aylett" in some email is NOT compliant to the JamesGram specification. I don't need the specification to define a "JamesGram Reception Agent", or even point out that a JamesGram can be transmitted in the body of an email. This is, I think, a very important point: by saying less, we avoid making assumptions about usage, and can still be clear. The Atom spec defines two file formats. You either support those formats, or you don't. A product /supports/ Atom or it does not. This is why I said initially that I have a problem with the word 'conform' - it's a sticky conceptual path. > >Or, more clearly, it produces Atom Feed Documents. If it > >produced something it claimed were Atom Feed Documents that weren't > >conformant, they wouldn't be Atom Feed Documents. > > Documents and Softwares are not the same thing. No, of course not. Software that works with documents, however, can choose to work with Atom Documents by following the spec, or can choose not to be avoiding it. We don't define an Atom Archiver either, because it's not necessary, practical or even advisable. > >Actually, since this is in the context of a security consideration, > >it's not a restriction on the processors AT ALL. > > Where what you just said is explained. You said before that > everything which is in the spec is normative and now you are saying > that this part is not normative? It is normative, but it is not placing a restriction on an Atom Processor. What it's doing is conveying useful information to people who write Atom Processors - information that will enable them to write better, safer software for their users. We're saying "Atom works like this, by the way you probably want to be careful about these bits". A bit like saying "a car works like this, but you might like to take some lessons first" - the lessons aren't part of the definition of a car. (Actually, I'm reminded of a story someone told me about a C++ compiler engineer who, on leaving his company, was presented with a book on learning how to program in C++ - because he didn't know. He didn't need to be able to /use/ C++ to implement it.) > I'm lost or does it show that it's > important to know which part of the specifications are informative > and which ones are normative? > http://atompub.org/2005/04/18/draft-ietf-atompub- > format-08.html#rfc.section.8 Aren't all parts normative unless stated otherwise? I think they are. > >It's saying "since > >Atom Processors are going to have to work with URIs/IRIs - they'll > >have to handle them - implementors should consult RFC3986 and RFC3987 > >for security considerations in doing this". > > where ? That's what the security considerations sections mean, or at least what I take them to mean. The security considerations sections of RFCs work in a certain way, and this is how I've read them in all sorts of different RFCs. > >>In the prose before it is said: > >>"If the "src" attribute is present, Atom Processors MAY use the IRI > >>to retrieve the content. " > >> > >>What is the behavior of the Atom processor when the MAY is not > >>implemented because it's optional and because it's not mandatory for > >>"Atom Processors" to handle URIs or IRIs. > > > >If we assume, as is I think reasonable, that handling URIs/IRIs is > >something that Atom Processors do by definition, then the last half of > >that question isn't relevant. > > "Assume" MUST not be part of a technical specification. That's the > whole problem here ;) Okay, bad wording. "If we accept that my understanding of what the other bits mean, then ...". English is such a pesky language, and it's bad enough we're using it for the specification, without having to /talk/ about the specification in it :-) (Bring back Wilkins, all is forgiven.) James -- /--------------------------------------------------------------------------\ James Aylett xapian.org [EMAIL PROTECTED] uncertaintydivision.org
