report_rom clarification about the validity of ROMs in case the report session was closed

[Johannes Schlatow]

> Usually, reports have the form of XML with the report name as top-level
> node type. So in this common case, the report consumer may check for
> this condition, e.g., to see if a pointer report as issued by nitpicker
> is valid, one may do:
> 
>   if (_config.xml().type() == "pointer") ...
> 
> If nitpicker closes the report session, report_rom will clear the
> dataspace. So the dataspace will start with a 0 instead of the top-level
> XML node. In this case, the 'Attached_rom_dataspace` returns the
> '<empty/>' node. In the hypothetical case that a valid report is called
> "empty", one could still check whether the dataspace contains a
> null-termination at the beginning:
> 
>   if (_config.local_addr<char const>()[0]) ...
> 
> In short, it is already possible to distingish both cases, isn't it?

Thanks for the clarification, Norman. I wasn't aware that the 'Attached_rom_dataspace' automagically returns the '<empty/>' node. Works for me ;-)

> > Or to put it another way: Initially, i.e. if no
> > report session was created (yet), the report_rom delivers an invalid
> > dataspace to the ROM clients. Shouldn't the report_rom restore this
> > state after the report session was closed?  
> 
> You raise a good point. But instead of confronting the ROM client with
> an invalid dataspace (which most ROM clients do not anticipate and
> therefore don't handle), I would rather deliver a zeroed dataspace
> initially to achieve the desired consistency. Thanks for pointing out
> this current deficiency!

Perfect.