[Bug 15390] [QT3TS] Serialization tests too liberal about errors

https://www.w3.org/Bugs/Public/show_bug.cgi?id=15390

--- Comment #4 from Dennis Knochenwefel <w3.org_bugs@knochenwefel.de> 2012-05-29 11:16:10 UTC ---
Your last statement enlightened me:

I now realized that in the given context I was misreading "performing" as
"supporting" because:

1. to comply with the serialization parameters seems to be optional ("the
processor may use these parameters to control the way in which the
serialization takes place"). So, I was not expecting that the reporting of
incorrect values is mandatory. Why is a processor given the freedom to ignore
serialization parameters, but being burdened with checking the correctness of
the parameters? Obviously, I might be wrong, but is "performing" really
intented to be used here?

2. if "performing" does not mean "supporting" here, then I think that some
points need to be rephrased, for example this sentence:

"If a processor is performing serialization, it is a static error
[err:XQST0119] if [...]"

I am wondering, how a processor is supposed to know in the static analysis that
it will perform serialization? This would be an oxymoron unless "performing" is
supposed to mean "supporting", or am I completely mistaken?

------------------------

To add more to this discussion: there are two types of incidents that might
occur and eventually be handled differently:

1. a particular serialization parameter value can be "not supported" by the
processor
2. a serialization parameter value can be "invalid" in accordance to the
serialization spec

I believe that the specification does not distinguish very precisely between
those which could be improved as well. I am not sure if the first incident type
is being taken care of at all (depending on what "incorrect" means)?

Thank you very much.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Tuesday, 29 May 2012 11:16:18 UTC