RE: Conflict between specification and Test Suite

Hi Philip,

 

I haven’t followed the whole discussion, so I may be off, but I think you’re seeing the test out to literally as the output of the specification.

 

The specification define what the information must be at the node level when processing the document.

 

The test output is just an arbitrary representation of that: We (not the spec) decide what is represented or not in the test output.

 

And it just happened that we decided to represent the linebreak information only when the node has a relevant information about storageSize as a whole. That is: the storageSize value is set for that node. It’s no different from, for example, the Localization Quality Issue: locQualityIssueEnabled has a default value of ‘yes’ but we show it only on the nodes that have a relevant LQI set of information (in that case a type or a comment is defined).

 

The table in the spec does not include default values for ‘auxiliary’ information. By that I mean information that is not meaningful without the ‘main’ information of the data category. For Storage Size: the ‘main’ info (without default) is the storage-size value, and both the linebreak and the encoding are ‘auxiliary’ information. Or for Localization Note there is a default for the type of note, but not for the note itself (the main information).

 

-ys

 

 

From: Philip [mailto:Philip.Oduffy@ul.ie] 
Sent: Monday, March 04, 2013 7:19 AM
To: Karl Fritsche; public-multilingualweb-lt@w3.org
Subject: Re: Conflict between specification and Test Suite

 

Hi Karl,
    Yes we saw this line, our interpretation of that was, that the default value of linebreak should be "lf", but not that the optional attribute must be added with the default value if not found. 
Adding the attribute is semantically different than the behavior specified in the quoted section. While the spec sets a default value for the attribute it doesn't say anything about injecting the attribute into the output when not in the input. Therefore, there is an inconsistence between the expected output files, which have the attribute, and the input files which do not. If the injection behavior is the desired behavior, then this should be explicitly stated in the spec. 

As per the table at: http://www.w3.org/TR/its20/#datacategory-description the StorageSize has no default value if the injection behavior be desired should that not be reflected in the table for this category.

On 04/03/13 13:00, Karl Fritsche wrote:

Hi Philip,

"An optional lineBreakType attribute. It indicates what type of line breaks the storage uses. The possible values are: cr for CARRIAGE RETURN (U+000D), lf for LINE FEED (U+000A), crlf for CARRIAGE RETURN (U+000D) followed by LINE FEED (U+000A), or nel for NEXT LINE (U+0085). The default value is lf."

I think you missed this sentence from the spec. The default is lf. So the tests are correct.

Cheers,
Karl

On 04.03.2013 13:53, Philip wrote:

Hey all, 
there appears to be conflict between the its 2.0 specification and the expected output files for the storage size category. 

The StorageSize category defines an optional attribute, lineBreakType, which has a default value of "lf". 
The specification explicitly states that this data category has no default values. 
The lineBreakType attribute appears in each of the expected outputs, regardless of the absence of the lineBreakType attribute in the input file. 

This behavior is not defined in the specification, http://www.w3.org/TR/its20/#storagesize, and seems to be a conflict as no defaults are specified for this category. 
Is this an issue with the spec or an issue with the expected outputs from the ITS Test Suite? 
Can someone clarify what the behavior is with data categories that have optional attributes with default values? 
Thanks, 
Philip