- From: Lloyd Rutledge <Lloyd.Rutledge@cwi.nl>
- Date: Mon, 23 Oct 2000 18:07:59 +0200
- To: Daniel.Veillard@w3.org
- cc: ph@w3.org, "Cohen, Aaron M" <aaron.m.cohen@intel.com>, "'thierry michel'" <tmichel@w3.org>, www-smil@w3.org, w3c-xml-linking-wg@w3.org
On Sat, Oct 21 2000 Daniel Veillard wrote: > How can you use XPointer if it's support is not required ? > XPointer cannot be subclassed. Either you use it or not. > Saying it's not mandatory doesn't solve the problem at > all. Will authors be allowed to use it ? > - if yes, then please don't subclass it or register a > new XPointer scheme (and manage to get the W3C Director > to agree this is a good thing) > - if no, then the problem is solved As Aaron and Philipp have said, the SMIL spec states that some attributes can use name fragment identifiers. This is a clear statement that establishes what happens to be a proper, albeit small, subset of XPointer -- though the spec makes no statement that these are actually XPointer, or should be treated as such. These URI's can, but don't have to be, passed to an XPointer process. The end result would be the same. Any URI attribute conforming to this specification would parse as XPointer, regardless of whether the document was transmitted as application/smil, text/xml or application/xml. A separate issue, but one the XML Linking WG is perhaps also referring to, is that the spec as it stands also explicitly does not require URI attributes that are XPointer to be processed in SMIL. Arguably, this implicitly allows XPointer in SMIL URI attributes, and allows SMIL browsers to perform XPointer processing on them. This, in turn, allows the same adoption path for SMIL documents and implementations that they have for media types: no media type is required in SMIL, but documents can use any media type, and systems can implement any. The market and community will decide what media types tend to be used in SMIL. As it stands, they can decide in the same manner for XPointer. And SMIL constructs exist to adapt XPointer-using components to systems that don't process XPointer, just as the same constructs adapt presentations to systems missing required media-processing components. This allows for a natural progression towards the integration of XPointer, and all media, into SMIL. Requiring XPointer implementation for all SMIL URI's would arguably delay significantly the introduction of SMIL, since full XPointer implementation is quite a task, and XPointer is not yet a recommendation. It would be great for XPointer to be used in SMIL, but that can happen after XPointer is released and implementations become available. Arguably, SMIL should not be held back waiting. The second alternative you mention would be to not allow authors to use XPointer ever, or at least until the next SMIL release, and similarly, to prohibit SMIL systems from processing XPointer. This is obviously not desirable, as it would prohibit market-driven XPointer integration into SMIL. -Lloyd -- Lloyd Rutledge vox: +31 20 592 41 27 fax: +31 20 592 41 99 CWI net: Lloyd.Rutledge@cwi.nl Web: http://www.cwi.nl/~lloyd Post: PO Box 94079 | NL-1090 GB Amsterdam | The Netherlands Street: Kruislaan 413 | NL-1098 SJ Amsterdam | The Netherlands
Received on Monday, 23 October 2000 12:08:04 UTC