Subject: [Ecrit] LoST errors

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Feb 2007 18:06:56 -0600

I may have raised this point before, but I can't remember.

LoST uses the element name in errors to distinguish the type of error.  I believe that this is a bad practice for a number of reasons.

1. From a data modeling perspective, elements names are the names of data types, whereas the type of error is a piece of information.  Protocol data is more appropriately contained within the data segments of the protocol.  This is the reason we have attributes with true/false values rather than relying on the presence or absence of elements.

2. From a forwards compatibility perspective, this choice introduces a potential error scenario.  Say that an extension defines a new error condition and corresponding message.  An old client that receives this error is no longer able to tell if the error is.  A client receiving this error cannot tell if there is an error in its parser, the communications stream, the server, or the request contents.  All it knows is that the response couldn't be understood.  Does the client retry?  Do they have to make a change to the request first?  Is it pointless even trying without a new version of LoST?  

   A clear strength of the old 3 digit error codes is their forward compatibility: even if you didn't know what 426 means, at least you could tell that you shouldn't try again without making some changes to your request.

Is the schema language any less able to extend the set of possible values for an attribute?  Is there any other reason not to send <error type="loop" ...> rather than <loop ...> aside from a meagre saving in bits?

Cheers,
Martin 

------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.  
If you have received it in error, please notify the sender
immediately and delete the original.  Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
_______________________________________________
Ecrit mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ecrit

---

From: Andrew Newton <[email-masked]>
Date: Thu, 8 Feb 2007 21:15:20 -0500

On Feb 8, 2007, at 7:06 PM, Thomson, Martin wrote:
> 1. From a data modeling perspective, elements names are the names  
> of data types, whereas the type of error is a piece of information.

You just made a generalization that took me 2 seconds to find a  
violating precedent.  See XML-RPC for the <fault> element.  And an  
error is just a type of response, so I guess next you are gonna say  
the response elements in LoST are data types.

>   Protocol data is more appropriately contained within the data  
> segments of the protocol.  This is the reason we have attributes  
> with true/false values rather than relying on the presence or  
> absence of elements.

I have no idea what you are talking about here.

> 2. From a forwards compatibility perspective, this choice  
> introduces a potential error scenario.  Say that an extension  
> defines a new error condition and corresponding message.  An old  
> client that receives this error is no longer able to tell if the  
> error is.  A client receiving this error cannot tell if there is an  
> error in its parser, the communications stream, the server, or the  
> request contents.  All it knows is that the response couldn't be  
> understood.  Does the client retry?  Do they have to make a change  
> to the request first?  Is it pointless even trying without a new  
> version of LoST?

Admittedly, if a client does know about a new error code or value,  
there is nothing that can be done to get it to know about them other  
than upgrade the software.  But that's true no matter how you  
represent the error.  Character strings are, after all, just numbers  
to a computer.

Second, the part about the client not knowing if the error occurred  
in the parser or communications stream is false.  We're talking based  
XML Namespaces here.

>    A clear strength of the old 3 digit error codes is their forward  
> compatibility: even if you didn't know what 426 means, at least you  
> could tell that you shouldn't try again without making some changes  
> to your request.

Clearly it wasn't strong enough for SMTP, because they had to create  
a confusing extended error syntax.

You seem to be confusing the representation of the type of error with  
classes of error, which is what the old style 3 digit codes do.

> Is the schema language any less able to extend the set of possible  
> values for an attribute?  Is there any other reason not to send  
> <error type="loop" ...> rather than <loop ...> aside from a meagre  
> saving in bits?

Yes, you seem to be forgetting that XML Namespaces aren't part of  
element or attribute content.  And therefore, it is less extensible.   
Take a look at the 'unsupportedProfiles' error.  It can return  
information specific to that type of error, whereas the method you  
describe would not allow that.

-andy

---

From: "Thomson, Martin" <[email-masked]>
Date: Thu, 8 Feb 2007 20:56:10 -0600

Inline...

> -----Original Message-----
> From: Andrew Newton [mailto:[email-masked]]
> Sent: Friday, 9 February 2007 1:15 PM
> To: Thomson, Martin
> Cc: ECRIT
> Subject: Re: [Ecrit] LoST errors
> 
> 

In my more than 2 seconds looking at <fault>, I can't see why you'd consider it as supporting your point.  Rather, I believe it's a case that reinforces my point.  The <fault> element doesn't change names, the structure within is data that is passed to the application layer.  Even in the struct it uses doesn't change the name of the fields, those are fixed too.

XML Schema had one thing right - define the structure in one part, the content in another (they messed up structure, but hey).  The separation is not kept in LoST.

> I have no idea what you are talking about here.

Take a simple case:
  <element>content</element>

The definition of element defines a data type.  The content is the information that you convey.  Elements and attributes and schema give structure to the information that they carry.  The names that you choose convey type information.

As for true/false; it doesn't matter.

> represent the error.  Character strings are, after all, just numbers

But you have no way to tell if you need to update your software, or if the server isn't just choking to death silently (frinstance, the <html> tag might indicate a badly implemented server spitting out a stack trace in HTML).

> in the parser or communications stream is false.  We're talking based

Alright, so some of the possibilities aren't particularly well thought out.  The point remains.

> a _confusing_ extended error syntax.

Say no more (emphasis added).

> classes of error, which is what the old style 3 digit codes do.

Maybe, but the point is that at least you get a clear indication of failure.  If it's not 2xx (maybe 1xx or 3xx), then something is wrong.

> describe would not allow that.

Namespaces don't provide extensibility; they just make it more manageable.  In any case, there is nothing stopping someone from defining different content based on the value of an attribute - after all, that's one of the reasons why RelaxNG is used, isn't it?

  badRequest = attribute code { "basicError" }, extensionPoint
  internalError = attribute code { "internalError" }, extensionPoint
  element ns1:error { badrequest | internalError }

/MT

---

From: Andrew Newton <[email-masked]>
Date: Fri, 9 Feb 2007 09:38:54 -0500

On Feb 8, 2007, at 9:56 PM, Thomson, Martin wrote:
> The definition of element defines a data type.  The content is the  
> information that you convey.  Elements and attributes and schema  
> give structure to the information that they carry.  The names that  
> you choose convey type information.

Ok.  What data type is <findService>?

> But you have no way to tell if you need to update your software, or  
> if the server isn't just choking to death silently (frinstance, the  
> <html> tag might indicate a badly implemented server spitting out a  
> stack trace in HTML).

Uh?  What?  First, you do know what the problem is: it is a tag you  
don't recognize.  Second, there is nothing special about this in the  
error case.  That bad <html> tag could service in the middle of the  
<mapping> content.  What then, skippy?

> Maybe, but the point is that at least you get a clear indication of  
> failure.  If it's not 2xx (maybe 1xx or 3xx), then something is wrong.

You get a clear indication of the failure with names.  Again, you are  
confusing 3 digit error code types with classes of errors.  In LoST,  
this isn't necessary.  Errors are errors.

> Namespaces don't provide extensibility; they just make it more  
> manageable.  In any case, there is nothing stopping someone from  
> defining different content based on the value of an attribute -  
> after all, that's one of the reasons why RelaxNG is used, isn't it?
>

Just how does this prove your point about 3 digit error codes?   
Besides, the use of namespaces is a well used, well understood way of  
extending XML.  I don't see what you have done as being any better.

You are simply saying, "I like to base the values of my if and switch  
statements off the content of elements, instead of the names of  
elements."  Well, good.  I like to drive slow in the fast lane.  Its  
a matter of taste.

-andy