Types command report labels as TYPE tag content

[GoogleCodeExporter]

What steps will reproduce the problem?
1. types command with no arguments 

What is the expected output?
Nothing or a number as content of the TYPE tag

What do you see instead?
Sometimes it is a label, sometimes it is a number

Comments:
For the types command perspective, the TYPE tag content should always be a 
number or nothing. 
DAS spec 1.6 draft 6:
The tag contents (optional) is a count of the number of features of this type 
across the segment.

For the features command perspective, the TYPE tag content should always be a 
string or nothing.
DAS spec 1.6 draft 6:
"The tag contents (optional) is a human readable label for display purposes. if 
Omitted, it is assumed the type ID is appropriate for display."

In both cases the type attribute within a SEGMENT tag is optional and 
deprecated but the RelaxNG does not allow it.

According to Andy:
On 11/08/2010 14:18, Andy Jenkinson wrote:
> Deprecated means to me that it is permissible but not expected. It should be 
possible to register a source with it in the response, otherwise it would be 
"removed" in the spec (removed elements are no longer permissible). IMO MyDas 
should not be providing this or any other deprecated attribute, but the 
registry should tolerate it, with a "deprecation warning" on the validation 
page if possible.

Original issue reported on code.google.com by leylaj...@gmail.com on 11 Aug 2010 at 1:21

[GoogleCodeExporter]

Solution:
1. Allow only numbers (or nothing) as TYPE tag content when it comes from the 
types command
2. Allow only label (or nothing) as TYPE tag content when it comes from the 
features command
3. As far as remove support for all deprecated stuff... I will wait for some 
more discussion about it.

Classes affected:
1. DasTypeE: serialize methods now include a boolean parameter featuresCommand 
that indicates whether or not they were called from the features command.
2. DasFeatureE: serialize method uses DasTypeE serialization with true for the 
featuresCommand 
3. DasCommandManager: typesCommandAllTypes and typesCommandSpecificSegment use 
the DasTypeE serialization method with false for the featuresCommand. 
typesCommandSpecificSegment  method does not serialize the attribute type for 
the SEGMENT ELEMENT because it is not supported for the RelaxNG

Original comment by leylaj...@gmail.com on 11 Aug 2010 at 2:34

[GoogleCodeExporter]

More on "remove support for deprecated"

MyDas will support deprecated attributes and responses as far as it is in 
accordance to RelaxNG schemas.
DasRegistry validator will allow it as well, with a deprecated warning.

On 12/08/2010 10:35, Jonathan Warren wrote:
> ok I've set up a warning for this in the code which will come up with a valid 
types but with warning next to it in red. Will have to go through the spec and 
find all the pink bits and do this for both 1.6 and 1.5 spec.
>
> On 11 Aug 2010, at 15:33, Andy Jenkinson wrote:
>
>> On 11 Aug 2010, at 14:38, Leyla Garcia wrote:
>>
>>> On 11/08/2010 14:18, Andy Jenkinson wrote:
>>>> Deprecated means to me that it is permissible but not expected. It should 
be possible to register a source with it in the response, otherwise it would be 
"removed" in the spec (removed elements are no longer permissible). IMO MyDas 
should not be providing this or any other deprecated attribute, but the 
registry should tolerate it, with a "deprecation warning" on the validation 
page if possible.
>>>>
>>>
>>> Mmm, If MyDas or any other should not support any deprecated thing, why not 
to remove it from the spec? I understand "deprecated" means "still allowed but 
be careful it will be probably removed in the next spec". So I think we should 
still support what is deprecated, or not? Supporting deprecated could makes 
transition easier for clients, or not?
>>
>> Well that was the idea... we are looking into allowing it in the RNG but 
having a warning on the validation page. 

Original comment by leylaj...@gmail.com on 12 Aug 2010 at 12:43

[GoogleCodeExporter]

Original comment by leylaj...@gmail.com on 25 Feb 2011 at 12:03

• Changed state: Fixed