RE: Inconsistency in the use of <position>?

Hi,

We'll check all errors references in moki document and add the position
element anywhere it is suitable.

Miguel

>>-----Mensaje original-----
>>De: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
>>checker-request@w3.org] En nombre de Francois Daoust
>>Enviado el: jueves, 05 de junio de 2008 16:05
>>Para: public-mobileok-checker@w3.org
>>Asunto: Inconsistency in the use of <position>?
>>
>>
>>Hi guys,
>>
>>There are a bunch of error messages (mostly HTTP_RESPONSE-xx and
>>LINK_TARGET_FORMAT-xx ones) that read like:
>>"The request to the resource PLACEHOLDER_1..."
>>or "...(in reponse to the resource PLACEHOLDER_1)..."
>>or "The linked resource PLACEHOLDER_2..."
>>
>>But on may also use the <position> element to reference a resource,
and
>>indeed, the <position> element is used each time we have a more
detailed
>>error
>>Wouldn't it make more sense to use a <position> element each time the
>>resource that triggers the message is not the main page?
>>
>>For instance, if you take a look at the mobileOK report for:
>>  http://mobile.lemonde.fr
>>
>>... you'll see that the report returns the following result:
>><result name="HTTP_RESPONSE-5" outcome="WARN">
>>  <info>WARN: The HTTP status (in response to the resource
>>http://logc2.xiti.com/hit.xiti?s=43260&amp;s2=27&amp;p=mobile_une&amp;
)ind
>>icates
>>redirection (status code 3xx) and the URI identified by the HTTP
>>Location header is a relative URI </info>
>></result>
>>
>>Having:
>><result name="HTTP_RESPONSE-5" outcome="WARN">
>>  <info>WARN: The HTTP status indicates redirection (status code 3xx)
>>and the URI identified by the HTTP Location header is a relative URI
>></info>
>>  <position tidied="false" type="GENERAL"
>>url="http://logc2.xiti.com/hit.xiti?s=43260&amp;s2=27&amp;p=mobile_une
&amp
>>;"
>>/>
>></result>
>>
>>would make the resource available in a fairly easy and consistent way
>>for machine consumption, instead of having to parse the info string in
>>search of the URI.
>>
>>Does that make sense?
>>Francois.
>>

Received on Friday, 6 June 2008 10:15:20 UTC