Re: Response to LC-2714

Hi Daniel,

A "Guidelines" section will definitively be beneficial. My only
recommendation is to make it user-friendly and do not rely on the
knowledge of the specification and inner workings from the readers.

I still think that these restrictive set of options should be at least
set as the default values for the Profile. Let the users tune the
compactness if it is not sufficient but provide a restrictive and common
base. Then it will be possible to actually make an evaluations at least
for the Profile default behavior.

Best Regards,
Rumen Kyusakov

On Thu, 2012-11-15 at 09:07 +0100, Peintner, Daniel (ext) wrote:
> 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 Monday, 19 November 2012 09:52:23 UTC