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-2709 Next: LC-2710
Subject: The Profile parameters Section: 4. Parameters representation Paragraph: "In such a case, the actual profile parameters (or fine-grained capping strategies) should be defined by an out-of-bound mechanism." Comments: The maximumNumberOfBuiltInElementGrammars and localValuePartitions parameters should not be mandatory to be set/communicated-out-of-bound in my opinion. For the number of build in grammar the encoder knows the number of the grammars so no need to be included in the header. On the decoder side if the implementation is "smart" it won't create a new build-in element grammar before examining the next event. If it is a xsi:type="SOME_EXISTING_TYPE", there is no need to create a new build-in element grammar. For the localValuePartitions again - no issues for the encoder if the parameter is not included in the header. The decoder on the other hand can create local value tables only if it has enough memory to do so. If it cannot support local value tables, it will only expect string values represented literally in the stream. Receiving a string as a compact identifier will produce error during decoding in any way if the decoder does not have enough memory.