[
Lists Home |
Date Index |
Thread Index
]
I read this earlier and almost responded; it appears
the WG is attemping a weak version of architectural
forms.
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?
len
-----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.
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.
> 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 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"
xlink="http://www.w3.org/1999/xlink";
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"
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 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*.
|
