[
Lists Home |
Date Index |
Thread Index
]
On Tue, Sep 17, 2002 at 07:03:29PM +0000, Arjun Ray wrote:
> Daniel Veillard <veillard@redhat.com> wrote:
>
> | On Tue, Sep 17, 2002 at 02:09:44PM -0400, Elliotte Rusty Harold wrote:
> | It's the crux of the problem. XLink designed a vocabulary (it was
> | what everybody in the Working Group felt we were asked to do
> | considering our charter).
>
> Nothing wrong with that, but XLink also established policy on deployment:
> colonified names with associated namespace "declarations". The quibble
We didn't. It's an XML vocabulary designed at W3C, expect it to be
anchored in a namespace ! The belief is that if you associate semantic
to a Name, you'd better anchor that name in a namespace, it's what
namespace were designed to do, remove ambiguity at the naming level to be
able to uniquely identify names in order to disambiguate them and be
sure you apply the right semantic rules to that node !
> about xlink:href versus plain old href aside, the policy "works" so long
> as at most one xlink:href is needed per element. IOW, the policy rules
> out a priori the possibility of multiple xlink:href's in a single element.
> Was this in the charter too?
It's the result of the unicity of attribute values + the fact that for
simple links it was considered sufficient. Yes that was a decision, in a
very large part conditionned by the framework. Your decisions are also
largely conditionned by the framework, otherwise XHTML1 would never have been
an attempt to directly retroffit HTML 4.01 into XML. Whether this leads
to successful decision on the long term is not easy to predict !
> | Another group is also free to design another vocabulary, reusing or not
> | XLink and the associated (minimal) semantic.
>
> XLink is neither usable nor reusable without a name mapping mechanism: its
> design constrainsts on *other* languages are draconian.
Because you have a very strong heritage. Forget about HTML, step back
a bit, breath some fresh air on top of a mountain and think about it again !
It's in general sufficient to simply tag with attributes from a foreign
namespace to add Linking semantic. No it is not draconian from an XML
point of view ... I disagree !
> I'll even propose the point of order that, whenever XSLT is used to pull
> implementation chestnuts out of definitional fires, it's time to start
> over.
Well if you have to fetch a remote resource to understand the linking
semantic of a given document, others could start saying "it's time to start
over" too ... I won't, I don't denigrate flexibility even if it complicates
implementation or the execution model. But I'm doubtful about the ways
to get this implemented as a reliable framework for general purpose Web
resources ! I would have loved to see XSLT succeed on the client, it's not
there yet, it may never come ... for me it's a lesson.
Daniel
--
Daniel Veillard | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
|
