- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Fri, 13 Sep 2002 16:57:44 +0200
- To: <www-forms@w3.org>
- Cc: "HTML WG" <w3c-html-wg@w3.org>, "Forms" <w3c-forms@w3.org>, <AndrewWatt2001@aol.com>
XML has what you may call 'host languages', and what you may call 'integration languages'. A host language has a root element, and may host other languages. For instance XHTML can host Math or SVG or many others by allowing those languages to be integrated into its structure. Integration languages on the other hand are designed to be hosted by other languages; they typically don't have a root element (though they may): Xlink for instance, XForms, XML Events. These usually have elements and attributes intended to be used by other languages. Some languages can be both host and integration (SVG for instance, and XHTML is also used this way by some). 1) Suppose we have an integration language 'XML Handlers', that has an element <script> a=b </script> and as an option the <script> element may have an attribute pointing to an external resource: <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" /> Well, now when we want to integrate XML Handlers with XML Security, we can't put a security preferences URI on the <script> element because it already has a URI. So we can't integrate the two: we have to redesign one of them; integration is impossible. We can't redesign XML Security because it doesn't have any elements, so we have to redesign XML Handlers. Well, we can't make the security preferences a child of <script> <script ...> <security ...> ... </script> because that would clash with the intended semantics of 'embed' on the URI on the <script> element. So how about making it a parent of <script>: <security xlink:href="/security/pref1.xsp" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" xlink:role="http://example.org/security"> <script xlink:href="/scripts/pop" xlink:type="simple" xlink:show="embed" xlink:actuate="onLoad" /> </security> Oh no. That contradicts the embed property too. Oh well, then we have to create a brand new extended link element: <secureScript xmlns:xlink="http://www.w3.org/1999/xlink" xlink:type="extended"> <resource xlink:href="/security/pref1.xsp" xlink:type="locator" xlink:label="security" xlink:role="http://example.org/security"> <resource xlink:href="/scripts/pop" xlink:type="locator" xlink:label="script" xlink:role="whatever" /> <resource xlink:type="resource" xlink:label="here"/> <arc xlink:type="arc" xlink:from="here" xlink:to="script" xlink:show="embed" xlink:actuate="onLoad" /> <arc xlink:type="arc" xlink:from="here" xlink:to="security" xlink:show="embed" xlink:actuate="onLoad" /> </secureScript> though I'm not sure where I'm going to put my inline script in this anymore (and I left a few things off, to simplify it and save my wrists). 3) And then along comes the XML Privacy group that introduces the XML Privacy specification that says that in order to reference a privacy preference file from XML, you have to put a URL ... no let's not do that today. All we wanted to say was <script src="/scripts/pop" xsecurity:preferences="/security/prefs1.xsp"/> HLink, just released, allows you to define this. http://www.w3.org/TR/hlink/ Steven Pemberton Chair W3C HTML Working Group, co-chair W3C Forms Working Group.
Received on Friday, 13 September 2002 10:57:50 UTC