[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

[Fwd: The problems with Xlink for integration languages]

• To: xml-dev@l...
• Subject: [Fwd: The problems with Xlink for integration languages]
• From: Ann Navarro <ann@w...>
• Date: Fri, 13 Sep 2002 16:31:42 -0400

>
>
>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.

• Follow-Ups:
  • Re: [Fwd: The problems with Xlink for integration languages]
    • From: Joe English <jenglish@f...>
  • Renamer-Att Again (was: Fwd: The problems with Xlink for integration languages]
    • From: Arjun Ray <aray@n...>
  • Re: [Fwd: The problems with Xlink for integration languages]
    • From: Arjun Ray <aray@n...>

• Prev by Date: OASIS announcement of WSS QoP discussion list
• Next by Date: Re: [Fwd: The problems with Xlink for integration languages]
• Previous by thread: OASIS announcement of WSS QoP discussion list
• Next by thread: Re: [Fwd: The problems with Xlink for integration languages]
• Index(es):
  • Date
  • Thread