[
Lists Home |
Date Index |
Thread Index
]
[please ignore the previous message, it was a cut and paste accident]
[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.
http://lists.w3.org/Archives/Public/www-html/2000Jan/0217.html
What may matter is if a host language provides for a "bridge" element
explicitly. (A bridge element is where the relvant semantics are in the
attributes only, the element type is merely a container.)
> 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"
xlink="http://www.w3.org/1999/xlink";
s-map="href src :auto s-auto"
s-auto="type show actuate"
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"
xlink="http://www.w3.org/1999/xlink";
p-map="href preferences :auto p-auto"
p-auto="type show actuate 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"
xlink="http://www.w3.org/1999/xlink";
s-map="href src :auto s-auto"
p-map="href preferences :auto p-auto"
s-auto="type show actuate"
p-auto="type show actuate 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 - or is that cargo
cult - 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.
What's wrong with using control attributes to carry mapping information?
You get all the flexibility you need in defining application attributes to
stay out each other's way.
|
