XPointer 1.0 last call review comments from SYMM-WG

XLink-WG members:

While the SYMM-WG has no specific objections to XPointer becoming a
candidate recommendation, we do not plan on using XPointer in the next
version of SMIL, SMIL-Boston. Since there are a couple of places in
SMIL-Boston in which XPointer-like addressing is used, we think that it is
important to explain our reasons for not including all of XPointer in
SMIL-Boston.

Why SMIL-Boston does not intend on using XPointer in SMIL-Boston
==================================================
The first XPointer-like use involves synchronization references to other
elements; our "sync-arcs" and "event-arcs". SMIL 1.0 uses a syntax that is
much like XPointer. Overall the response has been that this notation is
cumbersome and unfamiliar to authors. Additionally, XPointer syntax provides
a lot of powerful facilities that would not be very useful for timing
markup, such as the ability to navigate the DOM tree. What is desired is a
syntax that refers directly to identified elements with a minimum of
verbosity, and one that is more familiar, like ECMAScript. To answer this
need, SMIL-Boston includes a "dot" syntax to refer to elements their timing
relationships. Why did XPointer reject a dot notation, even as a simplified
alternate form?

The second use would be to support XPointer in the fragment identifiers on
URL's used to link into SMIL documents. This use fits nicely into the long
term strategy for SMIL and enabling reuse of arbitrary portions of SMIL
presentations. This functionality is included in the current public working
draft. However, at this point in time the need for this is not seen to be
worth the costs required to integrate generalized XPointer parsing into SMIL
players. So it is unlikely to make it into the final recommendation.

A related question. Is it legal to subset XPointer? At what level of
granularity?

-Aaron Cohen
W3C SYMM-WG Chairman

Received on Wednesday, 22 December 1999 13:40:19 UTC