Re: [TTML] ttm:item issues

On Tue, Dec 16, 2014 at 3:45 AM, Nigel Megitt <nigel.megitt@bbc.co.uk>
wrote:
>
> In last week's TTWG meeting our goal was to close a number of issues on
> TTML2, but we were unable to close any of those whose solutions were based
> on ttm:item as a solution, due to lack of clear consensus following
> Andreas's email [1]. Those are issues 244, 245, 246, 247, 248, 249, 250,
> 289, 290, 291 and 292 in the tracker.
>
> I would like us to be able to close those issues by the end of this week's
> meeting.
>
> Outstanding questions
> =====================
>
> The three raised points are:
>
> _____________________
> 1) Do we have a hard requirement that every document be validatable using
> XML Schema 1.0? Can documents be validated using XML Schema at all?
>

This isn't quite the correct question. What you are asking is whether every
specification constraint in TTML is validatable with XSD, not whether every
document is validatable. The former has never been the case, in TTML1 or
now with TTML2, but the latter has always been the case, and remains the
case with all new TTML2 features.


>
> The closest I can find to the requirement is in [2], requirement R604. In
> any case, there's nothing that demands a particular schema validation
> technique or version.
>
> Also, note that R601 specifies that individual metadata items should have
> both name and type as well as value, and the current solution omits type.
>

A type attribute is not necessary, since the definition of the named item
specifies the acceptable value syntax. So it can be inferred from the name.


> Possibly the addition of an optional type attribute would facilitate
> validation, using assertions in XML Schema 1.1, of the flavour:
>
>    <xs:assertion test="every $v in //ttm:item[@type='xs:positiveInteger']
> satisfies ($v = xs:positiveInteger($v))"/>
>
> i.e. verify that all ttm:items that have a type attribute whose value is
> xs:positiveInteger contain data that can be passed to the constructor for
> an xs:positiveInteger without raising an error [3], and after casting,
> have the same value (to return true even if the value is zero).
>
> Would this (addition of the type attribute) address the problem raised?
>
> _____________________
> 2) Should we integrate foreign namespace metadata elements directly in the
> spec?
>
> As far as I can tell, integrating XML from other namespaces is already
> permitted and does not need to be specified to be permitted.
> Glenn raised the point that circular references between specs need to be
> avoided too.
> John raised the point that in some cases it would be useful for TTWG to
> express a preference for some metadata "names" (including classification
> schemes).
>

When the WG reviewed Dublin Core metadata as part of the process to satisfy
R690 [1], we explicitly decided not to reference that spec or integrate its
vocabulary directly. Rather, we decided that in general we would not
integrate any other non-W3C vocabulary with the exception of items defined
in the xml:* namespace. We also considered direct use of the xlink:*
namespace in R292, but deferred adding link functionality in DFXP, so
didn't have to cross that bridge.

[1] http://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/

So, today, we have:

{ XML, XML Base, XML ID } ⇐ TTML ⇐ { EBU-TT, IMSC, ARIB-TT, ... }

This is a clean picture, easily understood and implementable. Putting a
loop in this would introduce significant and unnecessary complexity.


>
> It seems to me that this question does not need to be resolved prior to
> closing the ttm:item issues - does anyone disagree?
>
>
> _____________________
>
> 3) Should classification scheme be separable from item name?
>
> As indicated this is syntactic sugar. For me, though it is nice to have, I
> would not block closure of the ttm:item issues on this basis.
>

After reviewing this again, I see there is already a problem with the
drafted definition:

<item-name>
  : <named-item> <#14a5402c78780884_metadata-value-named-item>
  | xsd:token <http://www.w3.org/TR/xmlschema-2/#token>
  | xsd:anyURI <http://www.w3.org/TR/xmlschema-2/#anyURI>


The problem is that xsd:token turns out to be more general than I had
thought. So general that every value of xsd:anyURI also satisfies
xsd:token. I think what I really intended here should read:

<item-name>
  : <named-item> <https://mail.google.com/mail/u/0/#metadata-value-named-item>
  | xsd:NMTOKEN <http://www.w3.org/TR/xmlschema-2/#NMTOKEN>
  | xsd:anyURI <http://www.w3.org/TR/xmlschema-2/#anyURI>


So, even with this corrected definition, there still is a lexical overlap
between xsd:NMTOKEN and xsd:anyURI. In specifying that the latter should be
absolute, I assured that they would be distinguishable. If I allow for
relative URIs, then they may not be distinguishable.

Alternatively, I could define this to require only URIs, such as:

<item-name>
  : <named-item> <https://mail.google.com/mail/u/0/#metadata-value-named-item>
  | xsd:anyURI <http://www.w3.org/TR/xmlschema-2/#anyURI>


And then define each <named-item>
<https://mail.google.com/mail/u/0/#metadata-value-named-item> using bare
fragment identifier, i.e., starting with '#', then specify that any name
that takes the form of a bare fragment identifier be absolutized using a
TTML defined namespace, say a new one which we might define in a manner
similar to how we use Feature/Extension designators:

TT Metadata Items*none*http://www.w3.org/ns/ttml/metadata-items/

I could then define that xml:base on ttm:item or a default value is used to
resolve relative URIs. I could then define that the default is this new TT
Metadata Items URI, which could be overridden by a new <base/> element that
could appear inside <head/>, such as in:

<head>
<base type="metadata-items" xml:base="
http://me.com/ns/ttml/my-metadata-items/"/>
</head>

Alternatively, I could define the value space of <item-name> to only use
namespace qualified names, but not use URIs. For example:

<ttm:item name="ttmi:creationDate">...</ttm:item>

Then could make use of the existing XML namespace mechanism to bind
prefixes to defining entities (aka classification schemes).

This latter approach would likely be simpler.



>
> _____________________
>
> Nobody has raised any other reasons not to close the relevant issues.
>
>
>
> References
> ----------
>
> [1] Andreas's email re ttm:item
> http://lists.w3.org/Archives/Public/public-tt/2014Dec/0012.html
> [2] TTML Requirements http://www.w3.org/TR/2006/NOTE-ttaf1-req-20060427/
> [3] Xpath functions constructor for XSD types
> http://www.w3.org/TR/xpath-functions/#constructor-functions-for-xsd-types
>
>