Subject: Re: auto/embed is not node transclusion From: Rick Geimer <rick.geimer@xxxxxxx> Date: Fri, 14 May 1999 10:42:52 -0700 |
Paul, <note> 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. </note> 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 many industries). 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: <quote> 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? </quote> 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 level). 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. Rick Geimer National Semiconductor rick.geimer@xxxxxxx XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: auto/embed is not node transclu, Jonathan Borden | Thread | RE: auto/embed is not node transclu, Robert Streich |
Icon Contest Results, Sean Brown | Date | RE: XSL Limitation? Is this possib, Pete Beazley |
Month |