On Sat, Sep 30 2000 Chris Lilley wrote:
Lloyd Rutledge wrote:
The reason that the SMIL 2.0 spec does not require that
browsers process XPointer is that browsers don't and can't process
XPointer -- servers do. Please correct me if my understanding of the
general architecture is too primitive,
OK. Your understanding is not correct. Servers do not process the fragment
identifiers, because therse are not sent to the server (queries, following
a ? character, *are* sent to the server and perhaps that is what you are
thinking of?)
but servers process XPointer,
not clients -- right?.
No.
Clients send URI's to the given server,
yes. The fragment is not part of the URI and is not sent
the
server processes it and returns the located data to the client.
Yes, and then the client locates the relevant part of this resource using
the fragment identifier.
Thanks, Chris -- I stand corrected. Other main points from my
previous post still stand, though. Many SMIL constructs have values
that are XPointer subsets, rather than being SMIL-only. This
minimizes format re-learning and facilitates future further
incorporation of XPointer. Full XPointer is not required in SMIL, but
is explicitly enabled.
Having W3C require implementors of one standard be required to
implement several others from day one, if that correctly paraphrases
you, Simon, may have its merits -- and with the luxury of not being an
implementor myself, I'm inclined to see these merits. However,
(speaking as advocate-in-proxy) implementors are typically very hard
pressed to implement even the one standard for the first release,
especially is that release date is targeted to coincide with the
release of the format itself. This is complicated further if the
related standard itself is not yet released as a recommendation, as is
the case with XPointer. If every potentially related standard had to
also be implemented, it would be a long time before we see SMIL 2.0,
and other formats, first emerge in any practical sense. It may be
wise to slow release cycles as part of deliberate full step-by-step
inter-format integration, but it would put a hard-to-ignore strain on
implementors.
But regardless of the merits of either side, SMIL 2.0 is in last call,
and so it is unlikely such a large new requirement can be introduced.
In the end, with XPointer enabled in SMIL, it is the free market that
will decide to what degree XPointer is implemented and used in SMIL.
This is as true with XPointer as it is with the media formats
themselves that SMIL integrates. The implementors will listen to
their customer base. What sweetens the pot for implementors is the
availability of other XPointer implementations -- especially those in
open source, of course. The fact that the W3C XPointer page has an
XPointer implementation list that is empty is not encouraging [1], but
over time this will surely change. As customers and implementors step
forward and make themselves known, XPointer use will grow in SMIL,
XHTML and other formats.
-Lloyd
[1] http://www.w3.org/XML/Linking
--
Lloyd Rutledge vox: +31 20 592 41 27 fax: +31 20 592 41 99
CWI net: Lloyd(_dot_)Rutledge(_at_)cwi(_dot_)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