Re: License Draft: Tortured text re obligations...
Le 17 déc. 2006 à 11:24, Bob Wyman a écrit : There is, I think a bit of tortured text in James Snell's otherwise useful License ID[1]. 1.3. Terminology bob wyman [1] http://www.ietf.org/internet-drafts/draft-snell-atompub-feed- license-10.txt +1 -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: Atom and bidi (was: Re: Atom Syndication Format To Draft Standard?)
Le 3 oct. 06 à 08:20, James M Snell a écrit :
I think the suggestion of adding a dir attribute is a very good idea.
The great thing is that it can be done without any significant
backwards
compatibility concerns. The definition of the attribute is simple
enough:
atomCommonAttributes =
attribute xml:base { atomUri }?,
attribute xml:lang { atomLanguageTag }?,
attribute dir { rtl | ltr }?,
undefinedAttribute*
The attribute establishes the base direction of the text content of an
element (and plain text attributes, e.g. category/@label) and is
pretty
much identical in form to XHTML's dir attribute.
dir attribute in HTML.
http://www.w3.org/TR/html4/struct/dirlang.html#h-8.2
Though in Unicode 5.0 which has been just published
[[[
In UAX #9, Bidirectional Algorithm, for better interoperability,
the algorithm was modified to tighten up the conformance requirements
for using mirrored glyphs for characters. Higher level protocols are
discouraged, due to interoperability and security considerations. The
definition of directional run was changed to be the same as level
run, and the use of soft-hyphen with bidi text was clarified.
]]] -- Unicode 5.0.0
http://www.unicode.org/versions/Unicode5.0.0/
Tue, 29 Aug 2006 17:33:36 GMT
Maybe Martin or Richard can give us more information about it.
--
Karl Dubost - http://www.w3.org/People/karl/
W3C Conformance Manager, QA Activity Lead
QA Weblog - http://www.w3.org/QA/
*** Be Strict To Be Cool ***
Re: atom license extension (Re: [cc-tab] *important* heads up)
Le 7 sept. 06 à 01:29, John Panzer a écrit : This is a critical point. Without this, implementors cannot safely ignore licenses they don't understand (falling back to things like fair use if they can't find any licenses that grant additional copying rights). This means that implementors would likely have to drop feeds containing new licenses on the floor, meaning that new license schemes would never be deployed. People with legal background will confirm or not, but fair use doesn't exist in the same way in all countries. Offering a mechanism to provide licensing information is good. Encouraging a *legal* fallback mechanism is bad, very bad. IMHO, when the implementors do not understand the licenses, they have no rights to do things with content (because it's highly dependant of local laws) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: Atom license link last call
Le 16 août 06 à 01:16, Bjoern Hoehrmann a écrit : * James M Snell wrote: http://www.ietf.org/internet-drafts/draft-snell-atompub-feed- license-06.txt I do not quite understand feed-level licenses, the draft just says what they don't cover, not what they do cover. Say I make a feed with the five most insightful blog postings on international politics and I license the feed under the most permissive license possible. Can you then copy my list of entries over to your top five list? hmmm. I would not say that it's not useful but there are potentially troubles. We should have a use case reasoning with regards to the technology and *not* the legal aspects. I can indeed decide to license the content for all my feed items in one shot because I own the content. If it's the meaning of link at the feed level, no trouble. So with regards to the comment of Bjoern, what's missing is the scope nature of link, not necessary if it's right or not to license a republished content with difference license. Here it fells in the legal part of it, which has to been handle by the civic society. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: Copyright, licensing, and feeds
Reading the example from http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/ [[[ 3. The 'license' link relation An Atom link element with a 'rel' attribute value of 'license' is used to associate a copyright license with an Atom Feed or Entry. Atom entry, feed and source elements MAY each contain any number of license links but MUST NOT contain more than one with the same href value. The IRI specified by the link's 'href' attribute SHOULD be dereferenceable to return a machine or human-readable representation of the license. Implementors should note that, unlike the Atom rights element, which specifies a human-readable statement of the rights held over a entry or feed, license links apply only to the informational content of the containing element. That is, the presence of a license link relation within an Atom feed element does not extend a license over the various contained entry elements. Likewise, the presence of a license link within an Atom source element does not extend a license over the informational content of the containing entry. ]]] -- snell-atompub-feed-license-06.txt http://ietfreport.isoc.org/idref/draft-snell-atompub-feed-license/ #page-3 Thu, 13 Apr 2006 19:27:54 GMT # Some questions about specific use cases 1. Feed composed with multiple sources with different licenses. When a feed aggregator creates a feed from different sources (feeds) with different licenses, what should be the license of the resulting feed? feed (license ???) entry (license A) from feed X entry (license B) from feed Y entry (license B) from feed Y entry (license A) from feed X entry (license C) from feed Z … Defining the semantics of the attribute/element is cool, but on the side in the implementation it's not clear what should be by consuming products. As I said in a previous message, it's a tough problem. 2. Should there be a best practices document to invite tools developers to understand and implement licenses mechanism? (As I understand it's not the purpose of this draft). -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: Copyright, licensing, and feeds
Le 06-06-08 à 19:40, A. Pagaltzis a écrit : * Karl Dubost [EMAIL PROTECTED] [2006-06-08 04:30]: Which will not remove abuse :) Well, will anything short of not publishing your content? I think the point of such an effort is to make life easier for third parties who want to respect your wishes, not to make it harder for third parties who are intent on violating them. Agreed. And it's why my message (which was really badly written - fatigue) was separating the issue. It's a very important issue, and I really believe a clear spec, framework or let's say technical solution would improve the field. Definitely. I would love to see that happening as soon as possible. It's a mix between social and technical issues. Finding interoperable solutions would help to soften the social issues and frustrations. so again +1 a thousand of times ;) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: Copyright, licensing, and feeds
Le 06-06-08 à 05:17, John Panzer a écrit : I'm attempting to promote the use of explicit licenses in feeds, and Creative Commons is one great source of predefined licenses suitable for the kinds of things that people want to use feeds for today: http://creativecommons.org/weblog/entry/5928 +1 This is actually an interoperability issue: If I need to consult my legal department A bit more than that. As Elliotte said, there are a maelstrom of possibilities and not necessary easy to solve. These days, I'm blocking the access to *all* indexing bots (Google, Yahoo, technorati, etc.) because of the license issue. I had to fight with some of them. When we choose CreativeCommons, Share A Like - No commercial user, we expect that no commercial use will be done. It means no data profiling, no advertisement, etc. As Elliotte said too, it can be opposite, as one's would want to license its content, you can use it but you have to pay me in returns. * First simple solution: No commercial use. Aggregators, indexing bots, Re-bloggers, etc. MUST enforce the license. It means that a company like Technorati or Google could have a P3P declaration saying: if your data under this license XYZ, we will not be able to index them. and not index them. A Web blog readers which would data mining with the feeds, could say: Your data will not be used for commercial purpose when you are a paid subscriber. Then it will be users to decide the type of licenses, services and subscriptions they are willing to accept. Respect of the contract. * Difficult choice: Commercial use. Here it's very hard and we are entering in the nightmarish DRMs world. DRMs could be good if there were not mixed up with… TPM (Technical Protection Mechanism). There are efforts in this direction for Open DRMs http://www.openmediacommons.org/ http://odrl.net/ Which will not remove abuse :) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager, QA Activity Lead QA Weblog - http://www.w3.org/QA/ *** Be Strict To Be Cool ***
Re: Don't Aggregrate Me
Le 05-08-26 à 18:59, Bob Wyman a écrit : Karl, Please, accept my apologies for this. I could have sworn we had the policy prominently displayed on the site. I know we used to have it there. This must have been lost when we did a site redesign last November! I'm really surprised that it has taken this long to notice that it is gone. I'll see that we get it back up. Thank you very much for your honest answer. Much appreciated. You see educating users is not obvious it seems ;) No offense, it just shows that it is not an easy accessible information. And there's a need to educate Services too. Point taken. I'll get it fixed. It's a weekend now. Give me a few days... I'm not sure, but I think it makes sense to put this on the add-feed page at: http://www.pubsub.com/add_feed.php . Do you agree? Yes I guess a warning here plus a way of saying to users that they can change their mind later on might be useful. Yes, forged pings or unauthorized third-party pings are a real issue. Unfortunately, the current design of the pinging system gives us absolutely no means to determine if a ping is authorized by the publisher. Exact. We will run into Identification problems if we go further, with big privacy issues. I argued last year that we should develop a blogging or syndication architecture document in much the same way that the TAG documented the web architecture and in the way that most decent standards groups usually produce some sort of reference architecture document. Yes I remember that. I remember you talking about it at the New-York meeting, we had in May 2004. Some solutions, like requiring that pings be signed would work from a technical point of view, but are probably not practical except in some limited cases. (e.g. Signatures may make sense as a way to enable Fat Pings from small or personal blog sites. The thing is that a unique solution will not be enough. I may want to be able - to “authorize” services A, B and C to do things with my content, - but to forbid services X, Y and Z to use my content. Right now it's very hard to do that, except if you are a geek and you can block bots by their IP address and hoping that this IP will not change. It's why I would think that having services respecting license of contents would be a first step. In a service which aggregates the news from different sources. Some of the sources might be licensed for commercial use and some others not at all. Flickr has the start of a very interesting acknowledgement of that somehow. http://www.flickr.com/creativecommons/ * Maybe services like PubSub, Technorati, Bloglines, etc. should display the license in the search results. That would be a first step. * Second step would be to not use the content in a commercial activity if it has been marked as such. (data mining, marketing profile, etc.) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Don't Aggregrate Me
Le 05-08-25 à 18:51, Bob Wyman a écrit : At PubSub we *never* crawl to discover feed URLs. The only feeds we know about are: 1. Feeds that have announced their presence with a ping 2. Feeds that have been announced to us via a FeedMesh message. 3. Feeds that have been manually submitted to us via our add- feed page. We don't crawl. - How one who has previously submitted a feed URL remove it from the index? (Change of opinions) - How someone who's not mastering the ping (built-in in the service, the software) but doesn't want his/her feed being indexed by the service. I do not think we qualify as a robot in the sense that is relevant to robots.txt. It would appear that Walter Underwood of Verity would agree with me since he says in his recent post that: I would call desktop clients clients not robots. The distinction is how they add feeds to the polling list. Clients add them because of human decisions. Robots discover them mechanically and add them. If Walter is correct, then he must agree with me that robots.txt does not apply to PubSub! (and, we should not be on his bad list Walter? Please take us off the list...) It does apply, except if you give a possibility to each subscribers to ban a specific URIs. I think it's one of the main issue of the Web, too many implicit contracts. That's good because it helps to make the things easier, but at the same time, it means creating the infrastructure to deny explicitly. I guess the Feed industry is not eager too much to do that, because implicit data mining is one big part of the business. Basically imagine this scenario, when you go out every morning from your house, we take a photo of you and the way you are dress. It helps us to know how the people of this area are dressed then to create shops around. That will help us to send you appropriate catalogs of clothes you like, and to park a car with an ads with the products you usually like. Do you have the right to say No, I don't want to take a photo of me every morning for that purpose? -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Don't Aggregrate Me
Le 05-08-26 à 17:53, Bob Wyman a écrit : Karl Dubost wrote: - How one who has previously submitted a feed URL remove it from the index? (Change of opinions) If you are the publisher of a feed and you don't want us to monitor your content, complain to us and we'll filter you out. Folk do this every once in a while. Send us an email using the contact information on our site. (Sorry I don't want to put an email address in a mailing list post... We get enough spam already.) Where it is said? What you just said ;) http://www.pubsub.com/help.php http://www.pubsub.com/faqs.php You see educating users is not obvious it seems ;) No offense, it just shows that it is not an easy accessible information. And there's a need to educate Services too. - How someone who's not mastering the ping (built-in in the service, the software) but doesn't want his/her feed being indexed by the service. Providers of hosted blogging solutions or of stand-alone system should feel a responsibility to do a better job of educating their users as to the impact of configuration options (or the lack of options.) There are many blogging systems that don't support pings and others which normally provide pings but allow users to turn them off. Some systems, like LiveJournal even allow you to have a blog but mark it private so that only your friends can read it and pings aren't generated. What might not be happening as well as it could is the process by which service or software providers are educating their users. Services should work harder to educate their users. That doesn't solve the problem, when a third party - add my feed to such a service - send a ping to a service. Scenario: I'm a weblogger, I browse and see in my referer a link to my site. I go to the site, and see that the guy talked about me. He has a Feed but he's not indexed yet by PubSub, Technorati and others. I take the freedom to add his feed URL to the service and/or to ping the service because I want to know when this guy talk about me the next time. Well the problem is that this guy doesn't want to be indexed by these services. How does he block the service? BTW, it's a real scenario. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Don't Aggregrate Me
Le 05-08-25 à 06:44, James Aylett a écrit : I like the use case, but I don't see why you would want to disallow aggregators to pull the feed. You might want it for many reasons. One of my reasons which worries me more and more, is that some aggregators, bots do not respect the Creative Common license (or at least the way I understand it). http://creativecommons.org/licenses/by-nc-sa/1.0/ Attribution *No commercial Use* *Share A Like* When an aggregator or a service starts to do business with my feeds (Ads, data mining) IMHO it violates the license. Though there are not many ways to block the bots. * Some don't respect robots.txt * Blocking IP very difficult for the common user * Reading the Creative License by I don't know how many bots/ services respect it As James said, also, it might be something you are developing for an application and not suitable for aggregation. :/ Many issues. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Don't Aggregrate Me
Le 05-08-25 à 12:51, Walter Underwood a écrit : /robots.txt is one approach. Wouldn't hurt to have a recommendation for whether Atom clients honor that. Not many honor it. A while ago I had this list from http://varchars.com/blog/node/view/59 The Good BlogPulse NITLE Blog Spider Yahoo! Slurp The Bad Blogdigger Bloglines fastbuzz Feedster Crawler LiveJournal.com NIF PubSub Oddbot Syndic8 Technoratibot -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Don't Aggregrate Me
Bob, Thanks for the explanation. Much appreciated. Le 05-08-25 à 15:59, Bob Wyman a écrit : Karl Dubost wrote: One of my reasons which worries me more and more, is that some aggregators, bots do not respect the Creative Common license (or at least the way I understand it). It is important to re-iterate that a CC License only *grants* rights, it does not restrict, deny, or constrain them in any way. Thus, you can't say: The aggregator failed to respect the CC non-commercial use attribute. You must say: The aggregator failed to respect the copyright. Then I can tell that many aggregators use our content in a commercial way without me granting them this right. ;) Thanks again for the precision. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: geolocation in atom:author?
Le 05-08-21 à 11:45, Paul Hoffman a écrit : At 12:17 AM +1000 8/22/05, Eric Scheid wrote: #2 through #4 seem understandable, but what the heck is #1? The place where this feed was put together? The place where this feed was originally grabbed from? hmmm really? author namefoo/name geo:coordslocation#2/geo:coords /author What is location#2? a. The usual location of the author as in the place is living right now? b. The place of his origins? c. The place where he's blogging right now? d. The place he was when he had written the story that he will published in a few seconds but two days late with regards to the event date? I say that because for example in my case. a. My apartment, Montréal, Canada b. Rouen, France c. Cafe Laika, Montréal, Canada d. London, UK There's exactly the same kind of problems with photos. The location where the photos is taken, or the location of (one or more) regions in the photos. It's not that easy to answer at any level. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Protocol Action: 'The Atom Syndication Format' to Proposed Standard
Le 2005-08-17 à 13:14, The IESG a écrit : The IESG has approved the following document: - 'The Atom Syndication Format ' draft-ietf-atompub-format-11.txt as a Proposed Standard Congratulations for the good work. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Media extensions
Le 16 juil. 2005, à 13:53, James M Snell a écrit : Let's see if we can avoid the IETF process for now and encourage Yahoo and Apple to get together with the community to work on some a common approach, get some implementations out there to evolve it a bit, then evaluate later whether or not IETF standardization makes sense. FYI: Comparing Media RSS formats http://www.w3.org/2005/07/media-and-rss You can send comments, suggestions to improve the table. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Major backtracking on canonicalization
Le 05-07-07 à 14:12, Paul Hoffman a écrit : Without. That is explicitly the default for http://www.w3.org/TR/ 2002/REC-xml-exc-c14n-20020718/. Where does it state that explicitly? Just as with [XML-C14N] one may use the #WithComments parameter to include the serialization of XML comments. Meaning: if you don't include #WithComment, you don't get comments. H. not sure. [[[ 4. Use in XML Security Exclusive Canonicalization may be used as a Transform or CanonicalizationMethod algorithm in XML Digital Signature [XML-DSig] and XML Encryption [XML-Enc]. Identifier: http://www.w3.org/2001/10/xml-exc-c14n# http://www.w3.org/2001/10/xml-exc-c14n#WithComments Just as with [XML-C14N] one may use the #WithComments parameter to include the serialization of XML comments. This algorithm also takes an optional explicit parameter of an empty InclusiveNamespaces element with a PrefixList attribute. The value of this attribute, which may be null, is a white space delimited list of namespace prefixes, and where #default indicates the default namespace, to be handled as per [XML-C14N]. The list is in NMTOKENS format (a white space separated list). ]]] - http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/#sec-Intro I read Just as with [XML-C14N] one may use the #WithComments parameter to include the serialization of XML comments. So it's a MAY, but it doesn't say that when the parameter is not here that there's a MUST NOT include them. Going a bit further, because it is said Just as with [XML-C14N]. I follow the link [[[ The second parameter of input to the XML canonicalization method is a boolean flag indicating whether or not comments should be included in the canonical form output by the XML canonicalization method. If a canonical form contains comments corresponding to the comment nodes in the input node-set, the result is called canonical XML with comments. Note that the XPath data model does not create comment nodes for comments appearing within the document type declaration (DTD). Implementations are REQUIRED to be capable of producing canonical XML excluding all comments that may have appeared in the input document or document subset. Support for canonical XML with comments is RECOMMENDED. ]]] - http://www.w3.org/TR/2001/REC-xml-c14n-20010315#DataModel ok, so it's not really a default feature/behaviour but it seems something like a flag that you have to give. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines
Le 05-05-25 à 13:13, Mark Pilgrim a écrit : On 5/24/05, Karl Dubost [EMAIL PROTECTED] wrote: Validation is something very precise. It can be validated against a DTD, or against a Schema or another grammar language, etc. At least the Feed validator could become a Feed checker which develops a heuristic to check if the requirements of the specification are verified. :))) up to the validator authors :) This from the organization that added a fussy parsing option *enabled by default* in their (X)HTML Validator for almost 8 months. To avoid fussy comment, the W3C Mark-Up Validator exactly. The W3C Mark-Up Validator is maintained by a wonderful community of _volunteers_ And I wish we had more perl developers to help us because the main developers Terje, Nick, Ville and Olivier can't do everything. I wish we could have a Mark-Up checker that would develop also heuristic to check certain requirements of some mark-up languages that are not testable by a Schema or DTD validation. Basically, Mark, you are off-base, it was not a reproach to the feed validator. Quite the opposite, which I always found being a remarkable tool. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines
Le 05-05-23 à 18:04, Robert Sayre a écrit : Hi Karl. Thanks for the review. Some thoughts inline. my pleasure On 5/23/05, Karl Dubost [EMAIL PROTECTED] wrote: Requirement 01: Include a conformance clause. I tend to agree with Paul wrt conformance levels: http://www.imc.org/atom-syntax/mail-archive/msg10296.html :))) A conformance clause is helping you to do a bit more than the language used in the specification. RFC 2119 is a good choice to express the requirements of the specification. Nothing wrong with that. But it's a kind of hidden conformance layer and with a lot of regular different interpretation from the community. :) Let's go a bit further though. Let's say I'm a developer who's creating an authoring tool for Atom, so more a producer than a consumer application. Atom Feed Documents Atom Entry Documents I read An Atom Entry Document represents exactly one Atom entry, outside of the context of an Atom feed. Its root is the atom:entry element. Nowhere it is said that the root element of a conformant Atom Entry Document MUST be atom:entry. What is a conformant Atom Authoring Tool? The specification says at the start: This specification describes conformance in terms of two artifacts; Atom Feed Documents and Atom Entry documents. Additionally, it places some requirements on Atom Processors. If I read through the text Atom Processors are seen as consumers application, not producers. It means that all XSLTs, Web hosting services, etc can NOT claim conformance to Atom. :) I know it sounds strange. You can decide in the specification to forbid such a claim too, but at least it's better to be explicit than obvious hidden meaning which might be misinterpreted. Requirement 06: Create conformance labels for each part of the conformance model. NO. The conformance model being not completely clear. It's very hard to know what are the different type of conformance and then to put labels on them. See comment #1. I haven't taken the time :) to put the RFC 2119 together. It would help to understand what are: - conformant Atom Entry Document - conformant Atom Feed Document - conformant Atom Processor (- conformant Atom Producer) An Atom feed s/validator/conformance checker/ is a processor, though it doesn't have to display or render the Atom Feed Document. Will it be a problem with regards to the specification? I see also Atom Processors handle URIs. handle is not an RFC 2119. It means that it's not even optional, and not mandatory. Is it ok? Maybe Atom Processors MUST handle URIs.? 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. I'm not being picky, but just showing that a conformance model tries to tackle all these questions that might arise. It helps to really define how you implement the requirements of the specification. No consensus to make the schema normative. Everyone had a different reason for opposing it, as I recall. :) :))) no more feed validator then. :) Hope it helps. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines
Le 05-05-24 à 14:31, Paul Hoffman a écrit : I am completely unclear why this discussion is going on. Is there a desire on the part of the W3C to take the Atom work into the W3C? Are you insecure? Where did you read, imagine such a thing? The case has been settled for a long time by choice of the Atom Community. No trouble. If so, talking to the W3C/IETF liaison pair would be more appropriate than this mailing list. If not, then suggesting that our document should be more W3C-like seems fairly out-of-scope for an IETF WG. [I just removed initial thought here.] Could you clarify? Did you miss an email? [[[I have done the review of Atom 0.8 to ___test___ W3C QA Specification Guidelines with an external technical document and I thought it could be also useful to the Atom community. ]]] - http://www.imc.org/atom-syntax/mail-archive/msg15675.html and the rest, I'm replying to the questions. :) -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Review of Atom 0.8 Spec against W3C QA Specification Guidelines
Le 05-05-24 à 21:04, A. Pagaltzis a écrit : So it seems to me that your complaint is outside the scope of the specification, and, indeed, this WG. I had a lengthy discussion with Paul Hoffman out of the list to avoid unnecessary arguments on this list which has suffered it in the past. Just to remind the tone of my messages, it was not complaints, it was suggestions. I'm not asking people to do things with it. And I just replied to comments when people were asking about conformance. :) I still don't understand the first message of Paul, but that's another story which has no place on this list. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Atom 08 - HTML Version
Hi, I will use the HTML version http://ietf.levkowetz.com/tools/rfcmarkup/rfcmarkup.cgi?url=http:// ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- format-08.txt for something specific. Is it fine, or do people recommend another HTML Version of [[[ Expires: October 20, 2005 April 18, 2005 The Atom Syndication Format draft-ietf-atompub-format-08 ]]] - http://www.ietf.org/internet-drafts/draft-ietf-atompub- format-08.txt -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Review of Atom 0.8 Spec against W3C QA Specification Guidelines
of valid conformance claims. NO. Good Practice 06: Provide examples, use cases, and graphics. YES. Good Practice 07: Write sample code or tests. YES. Good Practice 08: When imposing requirements by normative references, address conformance dependencies. YES. Good Practice 09: Define unfamiliar terms in-line and consolidate the definitions in a glossary section. NO. Good Practice 10: Use terms already defined without changing their definition. YES. Good Practice 11: Use formal languages when possible. NO. You have used a formal language, the RelaxNG Schema but you didn't make it normative. Good Practice 12: Write Test Assertions. NO. Good Practice 13: Create subdivisions of the technology when warranted. N/A. Good Practice 14: If the technology is profiled, define rules for creating new profiles. N/A. Good Practice 15:Use optional features as warranted. YES. It seems it has been clearly defined when something is optional when it's not. Good Practice 16: Clearly identify optional features. YES. but could be better. Good Practice 17: Indicate any limitations or constraints on optional features. YES. Good Practice 18: If extensibility is allowed, define an extension mechanism. YES. A whole section is dedicated to it. Good Practice 19: Warn extension creators to create extensions that do not interfere with conformance. NO. Good Practice 20: Define error-handling for unknown extensions. YES. Good Practice 21: Explain how to avoid using a deprecated feature. N/A. Good Practice 22: Identify obsolete features. N/A. Good Practice 23: Define an error handling mechanism. YES. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Atom 08 - HTML Version
Le 05-05-23 à 16:54, Paul Hoffman a écrit : ]]] - http://www.ietf.org/internet-drafts/draft-ietf-atompub- format-08.txt The latter, definitely. The former makes good guesses about HTMLizing, but may have errors introduced by the automated guessing process. Thanks. :) The bad thing with IETF specification is that we can't give precise references to the text. I have used the text version instead. I'm sending another mail. -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Atom 1.0?
Le 05-05-09 à 23:48, Robert Sayre a écrit : I like Atom. Fear the non versioning. And yes there will be new version. I would even go as far to be sure to be able to identify the language in the document itself. The namespace should be enough for that. CSS was defined without versioning in mind and it's now a mess for tools developers. +1 to the suggestion of Atom 1.0 -- Karl Dubost - http://www.w3.org/People/karl/ W3C Conformance Manager *** Be Strict To Be Cool ***
Re: Posted PaceLangSpecific
Le 14 fvr. 2005, 23:19, Tim Bray a crit : On Feb 7, 2005, at 8:36 AM, Graham wrote: On 7 Feb 2005, at 8:29 am, David Powell wrote: Implementations MUST preserve the language context of language sensitive constructs. I have no idea what I'm being asked to do. Equally mystified by that sentence. -Tim Because maybe it's out of scope of Atom. :) David could maybe submit a test case to show what he meant. It's why a defined class of products would be very useful here. Implementations: Atom consumers (readers, aggregators, ) Atom producers? (xslt, scripts, human, ) Atom parsers? If it's about stocking information in a database and that this information is not lost, I don't see how it's related to Atom. It's a separate design issue. PGP.sig Description: =?ISO-8859-1?Q?Ceci_est_une_signature_=E9lectronique_PGP?=
