Re: [xml] libxml2 2.5.4 & libxslt ported, question about Xlink???

[Daniel Veillard <veillard redhat com>]

On Mon, Jun 09, 2003 at 09:37:07PM +0100, Ben Decker wrote:
> No, then xpath is not what I want. I am definitely NOT intersted in re-
> inventing the wheel, an if the is an accepted standrad API for linking the 
> content of external documents, then I want to make use of IT, not any 
> poor imitation I might cook up to 'look' like xlink, but really isn't.
>
> I looked over the xlink working draft, and it is quite extensive. I am sure 
> building a correct implementation involves more than using a look-alike 
> namespace.

  Okay, just to make things clear, I was W3C staff contact for the 
XML Linking Working Group who designed that spec and co-chair of the
group when it got published. I think I know the area well enough. You
can try to threaten to use another toolkit (xerces-c below), it won't
change anything, I know the spec, and that without rendering capabilities
there is little one can do.
  There is no XLink standardized *API* . XLink is pure syntax. It allows
to associate linking semantic to a given XML vocabulary. 
  All a toolkit can do is link detection. For XLink support you need
rendering, the toolkit will not do it for you, well at least not libxml2.
  All libxml2 could do is link *detection*. It's all it can offer and
the best way to implement it is to use XPath to lookup the XLink attributes
in the document. Then build the associated semantic in your application
using rendering blocks and UI interaction for link activation.

> I am only intersted using an accepted implementation of an approved 
> standard, little else.
>
> Then, hmmm.
> I think there is a xerces-c library addition that directly supports xlink, 
> somehow... I have to see.

  Without rendering that would be plain wrong. The only part which could
be automated link-wise are automatic link activation, and that's not something
you want the toolkit to do transparently. Link activation and transclusion
are typically not at the same level as something like inclusion, while the later
makes perfect sense being implemented at the parser level like XInclude,
the former really is far more complex and touch rendering and UI.
Implementing XLink in libxml2 makes no sense. Implementing XLink constructs
detections as a custom API in libxml2 is not a good idea, because the detection
is far better handled using an *existing API* like XPath for it.

  In a nutshell:
    - there is no XLink API
    - a toolkit without rendering nor UI can provide XLink detection only
    - libxml2 will not provide a specific proprietary XLink detection API
    - libxml2 provides XPath which can allow to easilly implement XLink
      detection
  If your problem is just including "the content of external documents" then
what you need is XInclude not XLink. If you need linking semantic, then
XLink is another beast and it does not work "just" by putting some magic
glue on top of a parser.

It makes clear why I suggested using XPath for this, I'm not trying to
push for a "poor imitation", I just know both the spec and the toolkit
very well and provided the best advice I could.
Now you can switch to Xerces if you want, no problem it's a conformant
XML parser too :-)

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/