Augment use of lwsp in ttp:{content,processor}Profiles (#170).

[skynavga]

See issue #170.

[nigelmegitt]

Looks good to me.

One slight oddity is that this definition of <lwsp> permits newlines and carriage returns: I would be very surprised to see this in attribute values of this kind, though I don't have a particular reason not to allow it.

[skynavga]

See [1] regarding rules for whitespace normalization in attribute values.

[1] https://www.w3.org/TR/REC-xml/#AVNormalize

[nigelmegitt]

Thanks, very helpful. Why do we not specify the post-normalization syntax rather than the pre-normalized syntax? That would allow us to replace <lwsp> in attribute syntax with <nsp> where <nsp>: #x20 after applying the normalization rules in [1] where [1] is your reference above? This would signal to implementers that a single normalization rule can be applied that then simplifies parsing syntax and implementations, for example by allowing removal of wildcards in regex, etc.

[skynavga]

Worth considering.

[nigelmegitt]

Not only that but it may be reasonable for some interchange contexts to constrain document delivery to have pre-normalized attribute values.

[nigelmegitt]

I've just dug into this a bit further and it turns out that traversing all the links from https://w3c.github.io/ttml2/spec/ttml2.html#reduced-infoset-attribute through the term definition and the reference into https://www.w3.org/TR/2004/REC-xml-infoset-20040204/#infoitem.attribute , we already specify attribute values in terms of normalized values in the reduced infoset, so the use of <lwsp> is actually rather difficult to achieve - anything other than a single #x20 character would have to be escaped. This seems like too much trouble! I suggest we simply replace <lwsp> in attribute value syntax as per #190.

[nigelmegitt]

On further inspection, permitting general <lwsp> is providing for escaped white space characters that would otherwise be normalized according to attribute information item. I do not think we actually want to permit this; presumably the intent behind proposing to allow white space is merely to indicate that post-normalization, a single #x20 character separates items within attribute values; an explanatory Note could be added to alert the more casual reader to the fact that other white space characters can be included, also leading and trailing ones, but that the syntax representation is for these having been normalized out.

[nigelmegitt]

@skynavga pointed out in today's TTWG meeting that in fact TTML1 already allows for general LWSP as delimiters between attribute value terms so the proposal to adopt the post-normalization form only could be a breaking change. On that basis we can go ahead and merge this and I will raise a new issue proposing post-normalized single white space. It could be that the best resolution to this would be to add an informative note, which I think is unfortunate but perhaps unavoidable.