Re: Comments on Architecture of the Web

On Thursday, June 26, 2003, 10:45:43 PM, Karl wrote:

>>Specifications of data formats SHOULD be clear about behavior in the 
>>presence of errors. It is reasonable to specify that errors should 
>>be worked around, or should result in the termination of a 
>>transaction or session. It is not acceptable for the behavior in the 
>>face of errors to be left unspecified.

KD> Does that mean for example that an invalid HTML file

The old attention to 'invalid HTML' does not scale in the wider world.
 In HTML, valid means 'valid to the DTD' and there are exactly two
 classes, valid and invalid.

 In XML, well-formedness is required. The DTD is optional; a schema
 (one of several schema languages) might be used instead of, or in
 addition to , a DTD; W3C XML schema does not answer 'is it valid'
 with a yes or no answer. Multi-namespace XML is common, and each
 namespace might use a different schema language (RDF for example has
 a RelaxNG schema - it does not have, and cannot have, a DTD).

KD> should be said
KD> invalid by the user agent to the user:
KD>         - not displayed
KD>         - warning?
KD>         - etc.

Depends on the error.

Not well formed - error message and nothing is diosplayed past the
well formedness violation.

Not valid to the DTD - well, maybe it doesn't have one. Maybe it is
valid to a schema (but schema does not mandate how to say which
schema). Maybe it is alid to the schema but the schema language cannot
express some constraints that are expressed in prose in the spec.

KD> But one could say if the resource is invalid, it is not anymore the 
KD> data format which was intended.

One could say that, but one would be oversimplifying. The SVG test
suite for example contains at least one invalid file and
implementations are required to display it correctly as a conformance
criterion. It does not conform to the DTD because it gas RDF in the
metadata element.

KD> Let say a flavour of an XHTML Company X, which is defined for a 
KD> specific case, a user agent of a company Y don't understand the 
KD> format, what the user agent should do in this case?

Flavour is bogus here. if company X adds to the XHTML namespace, they
are wrong. If they put their stuff in their own namespace well fine.
if they are not well formed then you display an error message 'not
well formed on line xxx'.

KD> So how do you define in your data format, that you have errors or 
KD> that you have done another flavour of the technology.

KD> When it's not valid, it's not HTML (c) Masayasu.

Brief, memorable, and untrue.

>>Final-form data formats are not designed to allow modification or 
>>uses other than that intended by their designers.


KD> I might be wrong, but I read the sentence as "Extension mechanisms in 
KD> a data format are forbidden".

You are wrong, final form means that it is very close to the concrete
end of the abstraction-concreteness axis. A legal document stored in
PDF is an example of a final form document. It can't be restyled and
will always print exactly the same way, which is why it is legally
alloed to be equivalent to an archived  paper copy.


KD> Two good resources for HTTP problems
KD>         http://www.w3.org/TR/chips
KD>         http://www.w3.org/TR/cuap

KD> They are both in the process of being republished... we are 
KD> reformating them to have the same presentation.

Now, that should no be necessary, just change the stylesheet ;-) yes
in practice, stylesheets depend on the paeticulaer namespace being
styled and the particular design patterns used 9class names, nesting
styles, etc).

KD> Thanks for this wonderful piece of work.
KD> Congrats to authors and editors.

Thanks for the review, and especially about errors because I have to
write something on that.


-- 
 Chris                            mailto:chris@w3.org

Received on Thursday, 26 June 2003 18:52:55 UTC