Subject: Review of Atom 0.8 Spec against W3C QA Specification Guidelines

From: Karl Dubost <[email-masked]>
Date: Mon, 23 May 2005 17:22:35 -0400

This is  a review of

[[[
Network Working Group                                 M. Nottingham, Ed.
Internet-Draft                                             R. Sayre, Ed.
Expires: October 20, 2005                                 April 18, 2005

                       The Atom Syndication Format
                       draft-ietf-atompub-format-08
]]] -
http://ietf.levkowetz.com/drafts/atompub/format/draft-ietf-atompub- 
format-08.txt

against W3C QA Framework: Specification Guidelines.
     http://www.w3.org/TR/qaframe-spec/
(A new version of Specification Guidelines will be published next  
week in Proposed Recommendation. This review has been made with the  
Editor's draft version which is not public yet).

Short Intro:
W3C QA Specification Guidelines has been designed to help W3C editors  
write better specifications. It focuses on how to define and specify  
conformance for a specification. Additionally, it addresses how a  
specification might allow variation among conforming implementations.

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.

The QA Specification Guidelines Specification is organized with a  
series of mandatory "Requirements" and optional "Good Practices". For  
each of them, you will find an explanation and a benefits analysis,  
plus techniques, examples, and other readings.

You might want to read the Test FAQ too.
     http://www.w3.org/QA/WG/2005/01/test-faq
to create a test suite for Atom and shared between developers
    http://intertwingly.net/wiki/pie/ConformanceTests

Best Regards.

Requirement 01: Include a conformance clause.
     NO. There is indeed a section which is an attempt of conformance  
clause but doesn't fulfill all the requirements that we could expect  
from such sections. It would be good to have a specific table of  
content item with the words conformance to help developers to  
understand right away the conformance model of the specification.

Requirement 02: Define the scope.
     YES. In the introduction of the document are given what the  
technology is about. Though it could be certainly improved, by giving  
a more systemic way of describing the scope.

Requirement 03: Identify who or what will implement the specification.
     NO. For example, we can see "Atom Processors" in the  
specification, but it is defined what's an atom processor. The list  
of class of products would help to define the conformance model, and  
then the conformance clause. What about authoring tools? What about  
validators? etc.

Requirement 04: Make a list of normative references.
     YES. The list of normative references is given.

Requirement 05: Define the terms used in the normative parts of the  
specification.
     NO. "Atom Processors" is not defined. Atom Feed is defined, Atom  
Entry as well. Some of the important concept really need more  
definitions. It's really important because it avoids broad  
interpretation of some terms.

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.

Requirement 07: Use a consistent style for conformance requirements  
and explain how to distinguish them.
     YES. the RFC is using a consistent style explained in Notational  
conventions.

Requirement 08: Indicate which conformance requirements are  
mandatory, which are recommended, and which are optional.
     YES/NO. Because of the lack of conformance clause clearly  
defined, it might be confusing. For example "This specification does  
not define a DTD for Atom Documents, and hence does not require them  
to be valid (in the sense used by XML)."  But a document could be  
valid against the RELAXNG Schema. Is there any reason to not make the  
schema normative?

Requirement 09: If the technology is subdivided, then indicate which  
subdivisions are mandatory for conformance.
     N/A. The technology seems to not be modular and then not  
subdivided.

Requirement 10: If the technology is subdivided, then address  
subdivision constraints.
     N/A.

Requirement 11: Address Extensibility.
     YES. Perfectly addressed.

Requirement 12: Identify deprecated features.
     N/A. None.

Requirement 13: Define how each class of product handles each  
deprecated feature.
     N/A. None.

List of Good Practices (OPTIONAL):

Good Practice 01: Define the specification's conformance model in the  
conformance clause.
     NO.

Good Practice 02: Specify in the conformance clause how to  
distinguish normative from informative content.
     NO.

Good Practice 03: Provide the wording for conformance claims.
     NO.

Good Practice 04: Provide an Implementation Conformance Statement Pro  
Forma.
     NO.

Good Practice 05: Require an Implementation Conformance Statement as  
part 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 ***

---

From: Robert Sayre <[email-masked]>
Date: Mon, 23 May 2005 18:04:39 -0400

Hi Karl. Thanks for the review. Some thoughts inline. 

> understand right away the conformance model of the specification.

I tend to agree with Paul wrt conformance levels:
http://www.imc.org/atom-syntax/mail-archive/msg10296.html

> interpretation of some terms.

Fully agree about "Atom Processors."

> hard to know what are the different type of conformance and then to

See comment #1.

> valid against the RELAXNG Schema. Is there any reason to not make the

No consensus to make the schema normative. Everyone had a different
reason for opposing it, as I recall. :)

> Requirement 13: Define how each class of product handles each

Robert Sayre

---

From: Karl Dubost <[email-masked]>
Date: Tue, 24 May 2005 11:08:26 -0400

> Hi Karl. Thanks for the review. Some thoughts inline.

my pleasure

> 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.

>> hard to know what are the different type of conformance and then to

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.

> reason for opposing it, as I recall. :)

:)))
no more feed validator then. :)

Hope it helps.

---

From: James Aylett <[email-masked]>
Date: Tue, 24 May 2005 17:19:35 +0100

>     "the root element of a conformant Atom Entry Document MUST be  

The implication (and I think it's pretty clear, but perhaps I'm used
to IETF documents) is that if we don't talk about MUST and SHOULD and
MAY, then a statement is an absolute requirement. We're saying that an
Atom Entry Document has a root which is an atom:entry element. So if
you have something that has a root that's something else, there's no
way it can be an Atom Entry Document.

I actually think that having a "conformant" layer is often bad -
because it suggests that "nonconformant" Atom Entry Documents might
exist and might mean something. By avoiding doing this, we define what
an Atom Entry Document is, and if you create something that doesn't
follow with that definition, you don't have an Atom Entry Document.

> What is a conformant Atom Authoring Tool?

An "Atom Authoring Tool" would be an authoring tool (however you want
to define it) that in some way uses Atom. Again, I don't see the need
for the word 'conformant'. The term "Atom Authoring Tool" isn't in the
draft, and it doesn't need to be.

> services, etc can NOT claim conformance to Atom. :)

Yes they can. 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). 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. 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.

> 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.

How can it be misinterpreted more than by giving the idea there might
be 'nonconformant' documents in some way? Can't we just assume that
the purpose of the spec is to define a document format (well, two
formats) that you (as a producer, consumer or whatever) can conform to
if you want? (And if you don't want, go do something else :-)

> and not mandatory. Is it ok? Maybe "Atom Processors MUST handle URIs."?

Why is it not optional or mandatory? It's a declaration of something
that an Atom Processor does - I take it as being a "by definition",
with reference to earlier statements of RFC 2119 requirement in the
document.

(I think the earlier statement is in 4.2.7.1 where we find that
"processors MUST compare atom:id elements", knowing that (4.2.7) "[the
atom:id] content MUST be an IRI".)

Actually, since this is in the context of a security consideration,
it's not a restriction on the processors AT ALL. 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".

> "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.

The behaviour of the Atom processor when the MAY is not implemented is
that the Atom processor doesn't retrieve the content. So it doesn't
have the content, which it may not care about.

> no more feed validator then. :)

A feed validator doesn't have to use a schema, but it could use it for
a non-normative check ("you may have problems" - or even kicking in
more lengthy checking code only when the schema is violated). This is
up to the validator authors.

James

-- 
/--------------------------------------------------------------------------\
  James Aylett                                                  xapian.org
  [email-masked]                               uncertaintydivision.org

---

From: Karl Dubost <[email-masked]>
Date: Tue, 24 May 2005 13:54:20 -0400

> 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.

> The term "Atom Authoring Tool" isn't in the draft, and it doesn't  
> need to be.

why?

>>  It means that all XSLTs, Web hosting
> Yes they can.

no for the reason I gave and no because there's no way to claim  
conformance to the spec. 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.

> They just can't claim to be Atom Processors unless they
> Atom Processors).

There's none.

> Something that produces an XML document that abides

Conformity of a document is not conformity of a product. Two  
different classes of products.

> Or, more clearly, it produces Atom Feed Documents. If it

Documents and Softwares are not the same thing.

> with reference to earlier statements of RFC 2119 requirement in the

You said it: "You take it" and I take it differently :) Our  
discussion here exactly shows that there's room for misinterpretation  
and nothing is obvious in a technical specification.
But don't worry I will not insist too much. If the Atom community  
considers it's enough for a good specification. Why not? The purpose  
of the exercise was to give help on things that might create troubles.

> 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? 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

> It's saying "since

where ?

> that question isn't relevant.

"Assume" MUST not be part of a technical specification. That's the  
whole problem here ;)

> up to the validator authors.

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" :)

Anyway. :))) It was just a message to help. :)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 May 2005 11:31:52 -0700

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? 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.

Could you clarify?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Karl Dubost <[email-masked]>
Date: Tue, 24 May 2005 14:51:11 -0400

Le 05-05-24 à 14:31, Paul Hoffman a écrit :
> 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. :)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 May 2005 13:44:15 -0700

>Are you insecure?

Well, I do sometimes worry my protocols aren't as long as those from 
other Working Groups, but I try not to think about it.

>The case has been settled for a long time by choice of the Atom 

OK, good. So why are we discussing where the Atom format document 
doesn't match up to W3C test specification guidelines?

>Did you miss an email?

No.

>]]] - http://www.imc.org/atom-syntax/mail-archive/msg15675.html

Right. You didn't say why you thought it would be useful, and then...

>and the rest, I'm replying to the questions. :)

That's the part that is confusing. Your responses sound a great deal 
like we should be making changes to our documents based on W3C test 
guidelines. For what purpose?

--Paul Hoffman, Director

---

From: "A. Pagaltzis" <[email-masked]>
Date: Wed, 25 May 2005 03:04:33 +0200

* Karl Dubost <[email-masked]> [2005-05-24 20:05]:
> > > It means that all XSLTs, Web hosting services, etc can NOT
> > > claim conformance to Atom. :)
> >
> > Yes they can.
> 
> conformance to the spec. 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.

If something produces documents that conform to the rules set out
for Atom Documents in the Atom Format specification, then it
produces Atom Documents. Are you suggesting that it makes sense
to state conformance in any other terms? If so, why?

I *could* see an argument for defining when an Atom Processor is
conformant; after all, interpreting a document is more ambiguous
job than generating one, and many desktop aggregators have poor
support for the full link model, f.ex.

Your complaints seem to hinge on a belief that the scope of the
specification should extend further than to specify exactly what
a document means. My understanding is that the WG has decided
that the format specification is to say exactly what the bits on
the wire mean, but not what how anyone should generate them or
what anyone should do with them once they have received them.

So it seems to me that your complaint is outside the scope of the
specification, and, indeed, this WG.

Regards,
-- 
Aristotle

---

From: Karl Dubost <[email-masked]>
Date: Tue, 24 May 2005 23:31:20 -0400

> 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.

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 25 May 2005 10:03:23 +0300

> verified. :))) "up to the validator authors" :)

The Feed Validator has always been a "Feed Checker" technically. I 
complained about the naming terminology when the Feed Validator came 
out. I don't expect the name to change now.

Even with validators that perform a precise check using a schema, it is 
important to know what kind of check the validator performs. In the 
case of Atom, the schema that ships with the specification is a RELAX 
NG Compact Syntax schema with embedded Schematron. When used with a 
RELAX NG validator that does not support embedded Schematron (eg. 
http://hsivonen.iki.fi/validator/), the validator will precisely ignore 
the embedded Schematron.

A hand-crafted checker can potentially be more useful than a validator 
that is limited to what is checkable using a given schema language. 
Case point: DTDs and attribute data types.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: Henri Sivonen <[email-masked]>
Date: Wed, 25 May 2005 10:07:55 +0300

On May 24, 2005, at 23:44, Paul Hoffman wrote:

> So why are we discussing where the Atom format document doesn't match 
> up to W3C test specification guidelines?

Atom has been advertised as "thoroughly specified" before it is even 
known what exactly the upcoming RFC will specify. Assessing the level 
of thoroughness using an outside metric makes sense to me. Whether the 
WG wants to act on the assessment is another matter.

-- 
Henri Sivonen
[email-masked]
http://hsivonen.iki.fi/

---

From: James Aylett <[email-masked]>
Date: Wed, 25 May 2005 13:57:26 +0100

> (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 :-)

> >The term "Atom Authoring Tool" isn't in the draft, and it doesn't  

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.

> 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.

> >abide by the rules for Atom Processors (and abide by any definition of

We have a number of MUST restrictions on Atom Processors, for instance.

> 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.

> 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.

> 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  

Aren't all parts normative unless stated otherwise? I think they are.

> >for security considerations in doing this".

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.

> "Assume" MUST not be part of a technical specification. That's the  

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

---

From: Mark Pilgrim <[email-masked]>
Date: Wed, 25 May 2005 13:13:52 -0400

> 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.

-- 
Cheers,
-Mark

---

From: Karl Dubost <[email-masked]>
Date: Wed, 25 May 2005 14:00:01 -0400

> *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.