Consider prohibiting use of Profile vocabulary

[cconcolato]

The value of being able to define profiles inside a DAPT document, to be able to refer to it via fragment identifiers seems low to me. We should prohibit this vocabulary in the document itself, but still allow people to refer to external profile documents if they need to.

[nigelmegitt]

I don't understand what's so bad about this vocabulary that it should be prohibited. Already no support for it is required, so if it's not valuable then people won't use it, but if it is useful they might use it and implement processors that handle it. It's not particularly different from most other features of TTML that aren't listed; it's just that we call it out rather than being silent about it.

There's even a note in §5.6.5 that says the vocabulary is not expected to be present.

The effects I can think of if we prohibit the vocabulary:

1. We block use of some (theoretical) generic TTML2 validators.
2. We force anyone who wants to define profiles to create them as separate resources and reference them, and require the validator that's processing them to fetch the extra resource.

Overall, my preference would be to leave the spec as-is, unless I'm missing some harm that the optional feature causes.