Re: [SpecGL Draft] D3 Good Practice: Define error handling for unknown extensions

Comments and suggestions in line

>D.3 Extensibility and Extensions
>
>Previous:
>---------------------------------------------
>Good Practice
>         Define error handling for unknown extensions. When defining 
> extensibility, include error handling instructions for when an extension 
> is not available or understood.
>---------------------------------------------
>
>Proposal:
>---------------------------------------------
>Principle:
>         Define error handling for unknown extensions

Depending on what we decide is a requirements for conformance to SpecGL - 
I'm not sure that this should be a Principle (i.e., requirement).  Is it 
always possible to define the error handling?


>Meaning:
>         When using a strict conforming application, users might have to 
> deal with documents, data which are considered invalid because they are 
> containing errors, or they are extended. Developpers will need to know 
> what must be the behavior of the application in such context.

This sounds more like a 'why care' rather than meaning.  Suggest:
Include error handling instructions for when an extension is not available 
or understood.

>Care:
>         A consistent error handling helps interoperability with regards 
> to usability. There is the well known Postel law which says "Be Strict in 
> what you produce, Be tolerant in what you accept". Though it has been 
> shown that often this has been the start of a nightmare for implementers 
> who have to deal with all the possible cases to recover from exotic 
> documents (non conformant or extended). Giving a consistent error 
> handling mechanism eases the work of developpers.

Nice!

>Techniques:
>There are typically two approaches: (from WebArch)
>         * Must ignore: ignore any content it does not recognize
>         Must ignore can be further refined, requiring that the unknown 
> item be  passed through unchanged to the next downstream process, while 
> other technologies simply discard it.
>         * Must understand: treat unrecognized markup as an error condition.
>
>         A good way to handle these two approaches is to have a way in the 
> syntax to distinguish which behavior is expected, e.g., mustUnderstand 
> attribute in Soap 1.2
>
>Don't forget to address all your classes of products. For example, an 
>authoring tool and a rendering tool might have to behave in a different 
>way or not.
>
>Example: (todo)
>         * SOAP 1.2
>         * XML: Well-formed or invalid...
>         * XHTML 1.0
>         * HTML 4.01
>         * Ruby?

regards
Lynne

Received on Friday, 25 June 2004 09:34:14 UTC