[
Lists Home |
Date Index |
Thread Index
]
>
>
>FYI - as promised, the HTML Working Group has released a document that
>begins to address issues with an alternative to XLink. That document is
>available at http://www.w3.org/TR/hlink/
>
>The chair of the HTML Working Group has sent out the following message
>as well.
>
>Steven Pemberton wrote:
> >
> > 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.
|
