These functions currently take the desired result units as the second argument. It is very complicated if the length units of the element are bytes, to ask for this length to be recast in characters due to the fragment-of-a-character on the end problem. In some sense there is quotient/remainder here, which means there are multiple operations here, not just one. There is the equivalent of floor (as many characters as fit, then fillByte) ceiling (every byte filled from some character), remainder (how many left over bytes are there). I think this is silly unless we have use cases driving this. I believe this restriction matches all use-cases I can think of: Restriction: If the element (first argument) to either valueLength or contentLength has length units of characters -> can ask for valueLength or contentLength in any of characters, bytes, or bits bytes -> can ask for valueLength or contentLength in bytes or bits bits -> can only ask for valueLength or contentLength only in bits. and it is an SDE otherwise. This insures that the result of these functions is always well defined. I understand why there is a box sized in characters and I need to know its size in bytes, but the opposite I can't see a use case for, and it isn't crisply defined even. Ditto for length in bits. If the box is sized in bytes I might want that in bits (so * 8), but if the box is sized in bits, and I ask for bytes, what do I want if there is a fragment of a byte? ceiling? floor? remainder? Thoughts? Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy<http://www.ogf.org/About/abt_policies.php>