This e-mail and all information included herein do not constitute a legal agreement accorded by INFOTRUST GROUP and its affiliates and subsidiaries. All legal agreements must be formulated in writing by a legal representative of INFOTRUST GROUP. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail by mistake, please inform us and destroy this e-mail and any documents it might contain. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. Finally, the recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. Thank you for your cooperation.
Quotes from the W3C XML Schema Recommendation: 4.3.1 length [Definition:] length is the number of units of length, where units of length varies depending on the type that is being *derived* from. The value of length *must* be a nonNegativeInteger. For string and datatypes *derived* from string, length is measured in units of characters as defined in [XML 1.0 (Second Edition)]. (result of clicking "characters") Consequently, XML processors must accept any character in the range specified for Char. The use of "compatibility characters", as defined in section 6.8 of [Unicode] [E67](see also D21 in section 3.6 of [Unicode3]), is discouraged.] Character Range  Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF] /* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */ So it would appear that spaces qualify. OTOH, under 'things I found on the way to other things', some parsers have at times had difficulties with 'special' characters, mis-counting a string such as "&&&&" by seeming to 'count' the characters in '&' in place of each ampersand. That sounds like a digression, but what it demonstrates is that the rules don't always get followed, no matter the best intentions. Given that there are attribute dialogs in AE that include 'lists' of values separated by spaces, this sounds like AE is applying that type of rule to determining the end of a given string in this context. Thus, your value containing a space is seen as two values, neither of which is of adequate length. Not how it 'should' be, per the schema, but how it is. Sounds like a PTC Trouble Call candidate, painful as that can be. Steve Thompson +1(316)977-0515