[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: well-formedness error


Danny Ayers wrote:

Greg Stein wrote:

In HTTP land, the phrase that we use is: "be strict in what you do, but
be lenient in what you accept."

I believe Anne was talking about XML well-formedness, rather than any HTTP (or TCP) characteristic. XML is not robust (by design), hence Postel's Law does not apply. Whether or not Atom as a system is intended to be robust is another matter.

Yes, XML is draconian by design. However, this characteristic only applies to a single component within the context of a larger system. To see how this applies in practice, consider Mark Pilgrims "Universal Feed Parser". The first thing it does is to invoke a "real" XML parser. The design of this interface is pluggable, so a choice of XML parsers is available. In a few cases, there are known issues in spec conformance with XML parsers that the Universal Feed Parser attemps to remedy.

In the cases where the input is not well formed, the Universal Feed Parser indicates this and goes into a scavenge mode, based ultimately on regular expressions, in an attempt to salvage whatever information is possible.

While this is robust, this is not "silent acceptance". And any improper interpretation of a well formed feed by the Universal Feed Parser would be treated as a bug.

The Atom spec would define exactly what
conformance *is*, and if a tool wants to allow some bending of the rules,
then that is the tool's perogative.

Indeed.

...
Currently there is considerable support for informing the user that a feed is invalid and also (optionally) providing a notification port server-side through which reports can be made. I personally think that the specification of what constitutes an 'Atom-conformant' tool should be on the job list, to encourage good practices.

IMO, the specification itself is what defines "Atom-conformant". It should
specify each of the rules necessary for conformance. Having a conformance
checking tool (and/or test suite) would be a huge win.

It is my fond hope to start turning my attentions from "standards venue chosing" to "conformance checking tool and/or test/suite generation" related activities.

If the user tool provides notification or other features, then that's up
to the tool. I don't think a specification ought to talk about that kind
of stuff -- just what "conformant" means. There is certainly room for
"non-normative" suggestions about tool behavior, but that would generally
be in an informational I-D rather than the Atom spec itself.

I don't think silent acceptance and best-effort display of erroneous data is generally a good idea. But that is out of scope for the spec, so there is a the need for (at least informational) extra docs.

Silent acceptance is not a good idea. However, I don't believe I saw where Greg was advocating that.

Cheers,
Danny.

- Sam Ruby