This document:Public document·View comments·Disposition of Comments·
Nearby:Efficient Extensible Interchange Working Group Other specs in this tool
Quick access to LC-2705 LC-2706 LC-2707 LC-2708 LC-2709 LC-2710 LC-2711 LC-2712 LC-2713 LC-2714 LC-2715
Previous: LC-2715 Next: LC-2706
Subject: Summary Section: All spec Paragraph: All Comments: The conformance with the Profile does not guarantee in any way a bounded memory for processing (for example not setting valuePartitionCapacity to 0 is enough to make a Profile complying implementation consuming huge amount of memory). Moreover a non-conforming to the Profile implementation can still use the Limiting the number of build-in grammars mechanism without declaring that in the EXI header. Without being an expert in the field my personal experience is that the EXI spec and even more the EXI Profile spec are very much requiring the users to be aware of some implementation issues in order to use the format in an optimal way. For example, I was involved to some small extend in the Smart Energy Profile 2.0 standard/draft that considers using EXI. Main goal is compactness but also lean processing. The knowledge on what is the optimal way to set all the parameters (schemaId, preserve, selfContained, valueMaxLength, valuePartitionCapacity and now the Profile parameters) is simply not there. The great flexibility provided by having so many things to tune is working against the wide spread adoption. The users should not be burdened by knowing what all these parameters mean especially the Profile ones that are purely connected to the implementation. Again, without claiming to be an expert and have a wide range of use cases in mind, I think a more restrictive Profile that actually provides some guarantees and not so much freedom of setting implementation parameters will be much more useful. In any case the actual use of the EXI Profile will require some "Application-specific Profile" that defines the fixed values for all these parameters. So why not preset all these parameters and provide some guarantees with a good memory usage vs compression trade-off? I know one size does not fit all, but then why defining an EXI Profile in the first place? 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.