OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] [Fwd: The problems with Xlink for integration languages]

[ Lists Home | Date Index | Thread Index ]

I read this earlier and almost responded; it appears 
the WG is attemping a weak version of architectural 

Host language == Markup application language 
Integration language == Architectural forms

It was noted when architectural forms were invented 
that an application language could be used as an 
architectural form and by a "top level form", an 
architectural form could become an application language.

Is this another case of changing the names and adopting 
a piece of another technology (namespaces) that makes 
the result more complicated than the original and 
ends up being less powerful?


-----Original Message-----
From: Arjun Ray [mailto:aray@nyct.net]

[Forwarded by Ann Navarro:]

Steven Pemberton wrote:

> XML has what you may call 'host languages', and what you may call
> 'integration languages'. 

A distinction without a difference, because an integration language can
always be endowed with a top-level form.  


What may matter is if a host language provides for a "bridge" element

> 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" />

      <script src="/scripts/pop"
          xmlmap="xlink s-map" 
          s-map="href src :auto s-auto"
          s-auto="type show embed"
          type="simple" show="embed" actuate="onLoad" />

(See http://lists.xml.org/archives/xml-dev/200208/msg01589.html and
followups for the basic idea.  It can even be improved.)

> 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"; />

      <myElement preferences="/security/pref1.xsp"
          xmlmap="xlink p-map"
          p-map="href preferences :auto p-auto"
          p-auto="type show embed role"
          type="simple" show="embed" actuate="onLoad" 
          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. 

Sure you can.  use a different attribute and map its name.

      <script src="/scripts/pop" preferences="/security/pref1.xsp"
          xmlmap="xlink s-map xlink p-map"
          s-map="href src :auto s-auto"
          p-map="href preferences :auto p-auto"
          s-auto="type show embed"
          p-auto="type show embed role"
          type="simple" show="embed" actuate="onLoad" 
          role="http://example.org/security"; />

> So we can't integrate the two: we have to redesign one of them;
> integration is impossible.

How about dropping the namespace colonification fetish instead?

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

Why not?  It's *trivial*.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS