Use of attributes in TTML namespace but NOT defined in TTML1

Content models of TTML elements are defined as Element Information Items and represented in XML. One example is the content model of the style element:

<style
  style = IDREFS
  xml:id = ID
  xml:lang = string
  xml:space = (default|preserve)
  {any attribute in TT Style namespace}
  {any attribute not in default or any TT namespace}>
 Content: EMPTY
</style>

The content models give a "general allowance" to use attributes of a specific namespace. In the above example, any attribute that is in the TT Style namespace ("http://www.w3.org/ns/ttml#styling") can be used.

My question is, if this is restricted to just the attributes of "http://www.w3.org/ns/ttml#styling" that are defined in TTML1 (see Section 5.3.1 of TTML1, Table 5), if also attributes are allowed that have been defined for the TTML Style namespace in a later publication of W3C (e.g. TTML2) or if from the element type defintion it doesn't matter where attribute is defined, it just needs to be in the TTML Style namespace.

My interpretation is that by the syntax definition all attributes are allowed to be added if they are in one of the namespaces in question, e.g. the following

{any attribute in TT Style namespace}

would make the following TTML legal (prefix tts is bound as defined in TTML1):

<style tts:foo="bar"... />

Although the namespaces defined TTML are in the authority of the W3C, a processor needs to accept a document with arbitrary attributes in the TTML style namespace. It is not possible to know which attributes in that namespace will be specified in the future (by whatever W3C standard group).

On Tue, Jul 25, 2017 at 12:38 PM, Andreas Tai ***@***.***> wrote: My interpretation is that by the syntax definition all attributes are allowed to be added if they are in one of the namespaces in question, e.g. the following {any attribute in TT Style namespace} would make the following TTML legal (prefix tts is bound as defined in TTML1): <style tts:foo="bar"... /> Although the namespaces defined TTML are in the authority of the W3C, a processor needs to accept a document with arbitrary attributes in the TTML style namespace. It is not possible to know which attributes in that namespace will be specified in the future (by whatever W3C standard group).

I basically agree with this interpretation. However, the appearance of an unknown attribute in a (known at a given time) namespace should not be a cause to reject the document, that is, unless the purpose of the processor is to verify strict adherence to whichever version of TTML is being used for that processing. Note also the following language that appears at the end of [1] in the original publication of TTML1: All TTML Namespaces are *mutable*

<http://www.w3.org/2001/tag/doc/namespaceState#namespacedef> [NSState] <https://www.w3.org/TR/2010/REC-ttaf1-dfxp-20101118/#nsstate>; all undefined names in these namespaces are reserved for future standardization by the W3C.

[1] https://www.w3.org/TR/2010/REC-ttaf1-dfxp-20101118/#vocabulary-namespaces Also, I note the existence of Issue #196 [2], which would seem to make this new issue a duplicate. If you agree, then you can close this one and mark as a duplicate. [2] #196

…

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#251 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCbzinppjyB7DzaSdY9CFPFqCI9_e4ks5sRjYmgaJpZM4OgH8f> .

I'm not sure I agree with this implied broader interpretation. Conformant TTML1 documents have the up to the defined TTML1 (e.g. tts:) namespace attributes and no more.

That said, well-implemented TTML1 decoders should be tolerant (and gracefully ignore) unknown TTML1 (e.g. tts:) namespace attributes in TTML namespaces.

On Wed, Jul 26, 2017 at 3:31 PM, Michael A Dolan ***@***.***> wrote: I'm not sure I agree with this implied broader interpretation. Conformant TTML1 documents have the up to the defined TTML1 (e.g. tts:) namespace attributes and no more.

I agree that an purported TTML1 document that contains extensions in TTML namespaces not known to TTML1 would not be strictly conformant. However, I think we can also recognize lax conformance as well. In a validation processor, I would expect at least a warning and perhaps an error to be reported (as a default) when encountering such extensions.

That said, well-implemented TTML1 decoders should be tolerant (and gracefully ignore) unknown TTML1 (e.g. tts:) namespace attributes in TTML namespaces.

Yes. And we baked that into the spec when we said, under Generic Processor Conformance, the following: The processor does not *a priori* reject or abort the processing of a conformant *Document Instance* unless the processor does not support some required (mandatory) feature specified or implied by a TTML profile declared to apply to the *Document Instance*. I view this as applying to documents claiming either strict conformance or lax conformance. Note, however, that we don't have any way for an author to signal they view one or the other of these models of conformance to apply.

…

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#251 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb7dmYaXPT8M-wkkIkO52EYyDJnXUks5sR7BAgaJpZM4OgH8f> .

OK, glad we agree on the original intent. Then, what's the issue and what should change in TTML1? I'm not seeing it. Maybe a clarification somewhere? But I do not agree with the original premise in this issue about an instance document being therefore "legal". We should stick to instance document conformance and decoder conformance and not introduce "legal", "strict", and "lax" at this stage.

Take a look at #196, which better expresses the issue IMO. [I'm waiting for Andreas input before closing this current issue #251 as a duplicate of #196.]

…

On Wed, Jul 26, 2017 at 3:52 PM, Michael A Dolan ***@***.***> wrote: OK, glad we agree on the original intent. Then, what's the issue and what should change in TTML1? I'm not seeing it. Maybe a clarification somewhere? But I do not agree with the original premise in this issue about an instance document being therefore "legal". We should stick to instance document conformance and decoder conformance and not introduce "legal", "strict", and "lax" at this stage. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#251 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAXCb9d7uFYZBnieqLypq6_jSFfKhCasks5sR7UMgaJpZM4OgH8f> .

@mikedo

@mikedo How do you interpret {any attribute in TT Style namespace}?

@mikedo

(@mikedo)

Conformant TTML1 documents have the up to the defined TTML1 (e.g. tts:) namespace attributes and no more.

@mikedo: Can you point me to the spec text that sets this constraint?

@skynavga: This issue should not be closed for now. #196 is not a duplicate of this issue. It is more related to processors behaviour, while my question is about document conformance against the grammar defined in TTML1.

@nigelmegitt

Below is my understanding of the steps involved with evaluation Document Conformance using the tts:foo="bar" example above against http://www.w3.org/TR/2013/REC-ttml1-20130924/.

Document Conformance is defined in Section 3.1 of TTML1
Criteria 1 and 2 are satisfied
Criterion 3 is satisfied and the document is associated with the Abstract Document Type defined in Section 4
Criterion 4 is satisfied since the content specification of style allows any attribute in the TT Style Namespace, which is mutable. [ed.: it is ambiguous whether the declared value of each attribute satisfies the type declared by the associated Abstract Document Type applies since tts:foo is not defined in the specification]

So AFAIK the document is conformant.

[ed.: this conclusion was changed from an earlier version of the comment]

Two important points in my mind:

how the document will be processed (successfully or not) by a conformant processor is not covered by the discussion above
the discussion above is only valid for the specific version of the specification mentioned above

Based on discussions with @nigelmegitt , a step (4) to Section 4 to prune attributes without a type declared by the associated abstract document type might be useful.

@nigelmegitt

@nigelmegitt

I could probably live with that as a solution for TTML1

Good!

however I also am still concerned about forward compatibility. If we put this change into TTML1 Third Edition, then what will the equivalent change be in TTML2? Certainly not the exact same text, because it prevents W3C from adding new vocabulary items in any potential supplementary specifications.

An option is to also add text regarding processor conformance. It could be mandated to ingnore unknown attributes (regardless from which namespace) and to not reject documents with unknown attributes. This should go in TTML2. It could also be discussed if it could be added as clarification in TTML1.

@TairT

An option is to also add text regarding processor conformance. It could be mandated to ingnore unknown attributes (regardless from which namespace) and to not reject documents with unknown attributes. This should go in TTML2. It could also be discussed if it could be added as clarification in TTML1.

@TairT Both!

See #196

@TairT

The Working Group just discussed Use of attributes in TTML namespace but NOT defined in TTML1 ttml1#251, and agreed to the following resolutions:

SUMMARY: General agreement to allow documents vocabulary not defined in the spec but extra wording to be proposed by @tairt

The full IRC log of that discussion

<nigel> Topic: Use of attributes in TTML namespace but NOT defined in TTML1 ttml1#251
<nigel> github: https://github.com//issues/251
<atai2> q+
<nigel> ack atai2
<nigel> Andreas: Two distinctions we made in the thread:
<nigel> .. 1. Attributes not defined in TTML1 - are they part of the TTML1 document model? Are they allowed in the syntax?
<nigel> .. 2. If the attributes are not yet defined in TTML1 but they appear, how should a processor behave and treat them?
<nigel> .. Both issues need to be discussed differently.
<atai2> q+
<atai2> ack atai2
<atai2> q+
<nigel> Glenn: The ambiguity is between style attributes defined in the TTS namespace and those
<nigel> .. listed in the TTML1 spec.
<nigel> Cyril: We should take the looser interpretation, allow things in the TTS namespace even if
<nigel> .. they are not defined.
<pal> q+
<nigel> Pierre: We should ask ourselves what problems that could cause for processors?
<nigel> Nigel: That's the same as processors seeing a TTML1 tts attribute profiled out.
<nigel> ack atai2
<nigel> Andreas: If you just want to make sure that expected vocabulary you expect then you
<nigel> .. need something stronger for say schema validation. If you make an error in attribute
<nigel> .. name spelling and allow a lax interpretation then it will not be spotted.
<nigel> ack pal
<nigel> Pierre: What's the difference between making a typo in a foreign namespace attribute and
<nigel> .. a TTML2 namespace attribute? And if a document has profiles that apply then they can
<nigel> .. impose stricter rules that a validator can use. Those things to me mitigate your point.
<nigel> Andreas: For foreign namespace attributes they are stripped out anyway and you do not
<nigel> .. care from a TTML1 processor perspective so that's different from TTML1 core vocabulary
<nigel> .. secondly, EBU for example did not put stricter rules in on the basis that the interpretation
<nigel> .. is that unexpected vocabulary is not allowed.
<nigel> .. Note Glenn's point in the thread that the schema provided a hint about the intent.
<nigel> Nigel: We need to get to a resolution here.
<nigel> Pierre: The downside I have heard is that schema validation won't catch some errors.
<nigel> Glenn: It significantly complicates schema validation if we use the looser interpretation
<nigel> .. because it will require adding a wildcard that does not exist now.
<nigel> Pierre: If you tell a validator to use a TTML1 model then I would expect a non-TTML1
<nigel> .. piece of vocabulary to generate a warning, which would show up typos.
<atai2> q+
<nigel> Nigel: I'm wondering about saying anyone who wants TTML2 defined syntax needs a
<nigel> .. TTML2 profile with stuff subtracted.
<nigel> Pierre: I wonder if we could add to the pruning list things not in the TTML1 defined vocabulary
<nigel> .. as well as non-TTML1 namespace content.
<nigel> Glenn: That would avoid the need for a schema change but the schema might end up
<nigel> .. overly restrictive.
<nigel> ack atai2
<nigel> Andreas: I wanted to ask Tess your opinion - there's a similar problem in WebVTT and
<nigel> .. maybe also HTML5, which is not XHTML5 because of the XML error handling.
<nigel> .. I wonder if there's a solution to separate document conformance from processor conformance.
<nigel> .. In WebVTT as far as I can see there is a clear line what an author is allowed to put in the
<nigel> .. document, but on the other hand the processor can support more. Is that correct?
<nigel> Tess: Yes that's correct.
<nigel> Andreas: So I think it makes sense in terms of general strategy to handle these cases
<nigel> .. like this.
<nigel> Glenn: I would not agree to use the same error strategy as in HTML and WebVTT.
<nigel> Pierre: The proposal on the table is to prune non-TTML1 defined vocabulary before validating
<nigel> .. for the purpose of TTML1 document conformance. After that profiles can do whatever
<nigel> .. they want.
<nigel> Tess: That's doing half of what Andreas suggests anyway.
<atai2> q+
<nigel> ack atai2
<nigel> ack
<nigel> ack atai2
<nigel> ack atai
<nigel> Glenn: The section to change would be §4 bullet 3. It would be consistent with the way
<nigel> .. we prune foreign elements.
<nigel> Andreas: I don't think so because foreign namespace attributes are specifically permitted
<nigel> .. in the model. Now we are discussing more - I am flexible if everyone agrees we should
<nigel> .. have this new approach, I can accept it but I still have concerns.
<nigel> Pierre: I think that's what we're saying. In addition to fixing bullet 3 of section 4, I think
<nigel> .. Andreas wants to state explicitly that, say, in §7.13 body, that it is any attribute in the
<nigel> .. TT style namespace not just those listed in the TTML1 vocabulary?
<nigel> Andreas: Yes, either this or do nothing. Then we don't want to do pruning for validation.
<nigel> Glenn: There's a major disconnect here - all of the foreign namespace elements and attributes
<nigel> .. are removed before considering element item definitions, therefore it is irrelevant what
<nigel> .. the "any attribute not in default of any TT namespace" is irrelevant for this purpose because
<nigel> .. it is post pruning. In fact it is misleading to have that in there in the first place.
<atai2> q+
<nigel> Nigel: If we do this we really need to have an informative statement explaining what is
<nigel> .. permitted and what is not.
<nigel> Pierre: I would add an example to section 4.
<nigel> ack atai2
<nigel> Andreas: We could add something to the end of 5.1 where we say [gap]
<nigel> Glenn: We've already done the work in the ED to prune out attributes not associated with
<nigel> .. the abstract document type.
<nigel> Pierre: My proposed step is for Andreas to craft some text that I can put in a pull.
<nigel> Andreas: From my interpretation the document model is strict but I would accept something
<nigel> .. else. I definitely will add some text to the issue for example to say in 5.1 that all undefined
<nigel> .. names in those mutable namespaces are part of the document model, regardless of which
<nigel> .. specification defines it.
<nigel> Pierre: I think we need an informative note and example explaining the difference between
<nigel> .. pre- and post-pruning syntax permission and behaviour.
<glenn> See https://github.com//issues/196 for issue where we updated section 4, item 3.
<nigel> Andreas: Okay I will add to the issue.
<nigel> SUMMARY: General agreement to allow documents vocabulary not defined in the spec but extra wording to be proposed by @TairT

@palemieux

As pointed out by @palemieux, we have already updated section 4, item 3 to explicitly prune unknown/undefined attributes from existing TT namespaces.

This text should be added as the end of section 4.

Although attributes and elements in TTML namespaces not defined in TTML1 are not members of the collection of elements and attributes defined by the associated Abstract Document Type, they can be included in a TTML document because they will be pruned by step 1 and 3.

This means that the following document would represent a Valid Abstract Document Instance although the attribute "tts:foo" and the element "foo" are undefined vocabulary items in the TTML namespaces.

<tt 
 xmlns="http://www.w3.org/ns/ttml" xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
 xmlns:tts="http://www.w3.org/ns/ttml#styling" xmlns:ebuttm="urn:ebu:tt:metadata"  ttp:timeBase="media" xml:lang="en"
 ttp:cellResolution="50 30">
	<head>
		<styling>		
			<style xml:id="paragraphStyle" tts:foo="bar" tts:textAlign="center" />
		</styling>
	</head>
	<body>
	    <foo>bar</foo>
		<div>
			<p xml:id="subtitle1" region="bottom" begin="00:00:00.000" end="00:00:05.000" style="paragraphStyle">One line Subtitle.</span>
			</p>
		</div>
	</body>
</tt>

The Working Group just discussed Use of attributes in TTML namespace but NOT defined in TTML1 #251.

The full IRC log of that discussion

<nigel> Topic: Use of attributes in TTML namespace but NOT defined in TTML1 #251
<nigel> github: https://github.com//issues/251
<nigel> Glenn: I'd reduce the example to a fragment here.
<nigel> Pierre: I'll take the action to add that.

A more minimal version of the above suggestion in the form of a note may be acceptable to me.

@skynavga

@skynavga to propose an informal note at the end of §4.1 to state that the application of schemas for validation is expected nominally to occur post pruning.

The following text could be added as note before the existing note of section 4.1:

The schemas are designed to be used for validation after the pruning steps 1-3 of section 4 have been applied.

Clarify validation of undefined items in TT namespaces (#251)

Navigation Menu

Repository navigation

Use of attributes in TTML namespace but NOT defined in TTML1 #251

15 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Use of attributes in TTML namespace but NOT defined in TTML1 #251

Description

Activity

andreastai commented on Jul 25, 2017

skynavga commented on Jul 25, 2017

mikedo commented on Jul 26, 2017

skynavga commented on Jul 26, 2017

mikedo commented on Jul 26, 2017

skynavga commented on Jul 26, 2017

palemieux commented on Jul 26, 2017

andreastai commented on Jul 27, 2017

palemieux commented on Dec 16, 2017

15 remaining items

andreastai commented on Jan 3, 2018

nigelmegitt commented on Jan 4, 2018

palemieux commented on Jan 9, 2018

css-meeting-bot commented on Jan 9, 2018

skynavga commented on Jan 9, 2018

andreastai commented on Jan 9, 2018

css-meeting-bot commented on Jan 9, 2018

skynavga commented on Jan 9, 2018

nigelmegitt commented on Jan 9, 2018

andreastai commented on Jan 9, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions