Response to LC-2714

Hi Rumen,

Thank you very much for your detailed review and your insights.

>  In any case, if every single application sets these parameters in a different way then the
> implementations won't be able to interoperate due to some memory issues or size constrains. What I
> see as a need is a Profile that provides some guarantees for resource constrained devices. For
> example, a conforming implementations should use only:
> - maximumNumberOfBuiltInElementGrammars = 0
> - valuePartitionCapacity = 0
> - maximumNumberOfBuiltInProductions = 0
> - localValuePartitions = 0
> - selfContained = false
> - preserve = all false
> - fragment = false
> - either strict schema mode OR "schemaId" set to the empty value schema-less mode
>
> Note that by fixing the values of these parameters will not only make the RAM consumption
> predictive but also lower the programming memory which is also an issue in some cases. The
> implementations of the Profile will be much simpler as a codebase as compared to implementing the
> generic version of the Profiles as it is now. In fact, the Profile as it is now will just extend
> the code and make it more complex which I believe is the opposite of what is needed for embedded
> applications.

We believe that each profile option has its right to exist. Depending on the actual use-case it is beneficial to tune the provided set of options to fulfill the demanded needs.

However, we agree that in some cases it is suggested to use the most restrictive set of options. That said, this is for example the case if the capabilities of the recipient are not known. In those cases it is best to select the most restrictive set of options. To reflect this circumstance we added a "Guidelines" section that will state this fact in the next updated version.

We hope this resolves your concern,

Thanks,

-- Daniel

Received on Thursday, 15 November 2012 08:10:38 UTC