[XSL-LIST Mailing List Archive Home]
Re: auto/embed is not node transclusion
Subject: Re: auto/embed is not node transclusion|
From: Rick Geimer <rick.geimer@xxxxxxx>
Date: Fri, 14 May 1999 10:42:52 -0700
I've replied to all the lists you posted to, but I'm unsure if this reply will be
accepted by all of them, since I am only registered on the XSL list. If you decide
it is appropriate to forward this reply to the other lists if it doesn't appear on
them, feel free to do so.
Thank you very much for your analysis and comment. After reading your post, I had a
discussion with Bob Yencha, who was instrumental in developing the Pinnacles
standard from the beginning, to find out the actual intent of the reflection
element. Secondly, we discussed what we would like to see from a standards point of
view to solve this and future problems (i.e. a generic solution that could apply to
First, I was a little suprised to find out that the intent of the reflection
element is actually somewhat cloudy and ill-defined (perhaps XLINK is a good match
after all :-). It was originally defined as an SGML CONREF, but due to religious
wars among several vendors as to what CONREF really was, it was decided to just use
ID/IDREF, and define in the text of the standard what the expected behavior was
from a Pinnacles compliant application. From what I gather, the expected result is
more of a text-level transclusion than a node-level one, i.e. if the source
contains "V<sub>CC</sub>", then the result would only contain the text "VCC". I
think the purpose of this was to avoid some of the grove transformation problems
you mentioned in your reply.
Now, what would we like to see from a standard? In short, clarity. XLINK should
either define the expected results of the specified behaviors absolutely and
unambiguously, or get rid of them. Your quote below sums it up well:
You could argue that I am being a purist. Embedding PDFs or JPEGs would
"probably" have the behavior of just *displaying* them inline but
embedding an XML element would have the behavior of node-level
transcluding it. Browsers would "probably" implement it compatibly. Are
you comfortable with these probably's and with trusting the
like-mindedness and good will of browser vendors?
No I am not comfortable with trusting the like-mindedness and good will of browser
vendors. However, neither am I comfortable ditching behavior altogether. One could
argue the following point until the cows come home, but there are times where the
symantics and expected behavior of an application are so intertwined as to be
almost one and the same. I think this is the case with transclusions (text or node
I would feel comfortable removing behaviors from XLINK only if they were to appear
in a well defined transclusion standard separately. Perhaps there should be a move
to form an XTRANS standard, which defines text and node level transclusions that
can be implemented unambiguously among browsers and other XML applications.
Ideally, it would address all the points you raised in your original post (not
included here because of it's length).
I disagree strongly, however, that this should stricly be the realm of XSL. Tying
the symantics of a transclusion to a styling language, however well thought out and
powerful it is, does not sit well with me. The data itself needs some way to
specify the intended behavior in this case.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list