- From: Paul Grosso <pgrosso@arbortext.com>
- Date: Fri, 13 Sep 2002 12:19:19 -0500
- To: "Steven Pemberton" <steven.pemberton@cwi.nl>, <www-tag@w3.org>
At 18:52 2002 09 13 +0200, Steven Pemberton wrote: > <script src="/scripts/pop" /> > >and someone complains that this should use XLink, so it gets changed to: > > <script xmlns:xlink="http://www.w3.org/1999/xlink" > xlink:href="/scripts/pop" xlink:type="simple" xlink:show="embed" > xlink:actuate="onLoad" /> > >2) Suppose we have another integration language "XML Security" that requires >adding references to security preference files via a URL >xsecurity:preferences="..." > > <myElement xsecurity:preferences="/security/pref1.xsp"> > ... > </myElement> > >Someone says they should make this XLink compatible, so they instead >just define a new xlink:role "http://example.org/security": > > <myElement xlink:href="/security/pref1.xsp" xlink:type="simple" > xlink:show="embed" > xlink:actuate="onLoad" xlink:role="http://example.org/security" /> I don't know what I think yet about Steven's actual point (the rationale for HLink), but I think the above examples harbor a misconception. The "embed" value for xlink:show has no "inclusion" semantics. The embedding is just at a presentation level. It was meant to handle such things as embedding a graphic image. (I have long argued that the "embed" value was a mistake that should never have been allowed in XLink.) So Steven's examples which (I think) are meant to imply some kind of inclusion semantics (e.g., act as though the referenced script code were inline) could not use XLink's embed. XInclude maybe, but not embed. paul
Received on Friday, 13 September 2002 13:20:52 UTC