cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: First live Cocoon2 site? [cheat]
Date Tue, 23 May 2000 17:21:55 GMT
Ross Burton wrote:
> 
> > > Wouldn't that require all links to be declared using xlink?
> 
> > You touched a nerve: yes, it would require _all_ links to be declared
> > using XLink, at least, simple xlinks (extended xlinks become quite evil
> > on the server side).
> 
> Thought so.

Please, allow me to rephrase: since simple xlinks in fact _are_ a simple
version of extended xlinks, the above is misleading.

What I intended to say is that 

  <person xlink:href="http://www.apache.org/~stefano/"
xlink:type="simple">
   <name>Stefano Mazzocchi</name>
   <email>stefano@apache.org</email>
  </person>

is much easier than

  <person xlink:type="extended">
   <link xlink:href="http://www.apache.org/~stefano/"
         xlink:type="locator" xlink:role="remote"/>
   <go xlink:from="local" xlink:to="remote" 
       xlink:show="replace" xlink:actuate="onRequest"/>
   <name xlink:role="local">Stefano Mazzocchi</name>
   <email xlink:role="local">stefano@apache.org</email>
  </person>

even if they are totally equivalent in functionality. Don't be scared by
verbosity, thought! since, given a proper schema, the right above can be
written as

  <person>
   <link xlink:href="http://www.apache.org/~stefano"/>
   <go/>
   <name>Stefano Mazzocchi</name>
   <email>stefano@apache.org</email>
  </person>

which is only slightly more verbose.

Simple XLinks are links that originate _always_ locally and have only
one arc, visually is

  local ----> somewhere

while extended links can be

  remote ----> remote

or 

    +--------> remote1
  local -----> remote2
    +--------> remote3

or even more complex sets like

    +--------> remote1 ----+
  local -----> remote2 <---+
    +--------> remote3

I still don't have clear ideas on how useful those extended links are in
real life (given that HTML didn't lack hyperlink capabilities just using
simple links), but XLink provide the idea of "Linksets" which can be
very useful in our sitemap to avoid hardcoding of links between files
instead of URI resources.

Well, I admit it's too foggy out here to see something.

> > It is possible to declare your xlink stuff in your DTD/XMLSchema and use
> > them everytime you reference that element. yes, it's possible.
> >
> > But, there are some drawbacks: for example, to write an XHTML link and
> > allow Cocoon _understand_ this is a link, you must do
> >
> >  <a href="mylink" xlink:href="mylink">
> 
> Yuck!  But who uses XHTML except for sending to the client?

Right.

There is a solution to this problem: XML Schema provides the ability to
"inherit" elements and attributes, something that the SGML world tried
to do with HyTime implemented as processing instructions, but failed due
to its intrinsic complexity (this was called "Architectural Forms").

For XMLSchema, this is rather simple:

 <xs:schema xmlns:xs="http://www.w3.org/1999/XMLSchema"
            xmlns:xlink="http://www.w3.org/1999/xlink"
            xmlns="http://www.w3.org/1999/xhtml"
            targetnamespace="http://www.w3.org/1999/xhtml">
    ...
    <xs:element name="a">
     <xs:attribute name="href" type="xlink:href"/>
     <xs:attribute name="xlink:type" use="fixed" value="simple"/>
     ...
    </xs:element>
  </xs:schema>

which would allow W3C to define XHTML in such a way that schema-aware
applications can understand that <a> is, in fact, a simple link in its
very semantic definition, without necessary requiring duplication.

> > which clearly sucks. Yep, you have to specify the href twice, first time
> > in the XHTML namespace, second time in the xlink namespace. This because
> > they mean different things depending on the namespace they belong to.
> > But in more structured markup, it's a lot better:
> >
> >  <person xlink:href="http://www.apache.org/~stefano/">
> >   <name>Stefano Mazzocchi</name>
> >   <email>stefano@apache.org</email>
> >  </person>
> 
> Far more like it.  I'm happy with this.

When XMLSchema will be a reality, it would be even simpler

  <person homepage="http://www.apache.org/~stefano/">
   <name>Stefano Mazzocchi</name>
   <email>stefano@apache.org</email>
  </person>

then the attribute "homepage" would inherit "xlink:href", without
requiring document writers to ever know anything about XLink at all!
(which is why HTML was so successful)
 
> > > Or is this a future idea when the parsers catch up with the specs?
> >
> > No, xlink will be required for server side operation and it's up to you
> > to come up with XSLT transformation for those xlink-ed elements or send
> > them directly to xlink-supporting browsers.
> 
> Sure.

In case of XMLSchema-aware browsers (if ever!), this would happen
automatically... but, as always, Cocoon will be there to patch those
cases where client-side is not powerful enough to work as recommended.
 
> > Xlink is required by the server side crawlers that generates the
> > rendered pages to understand _where_ to go next without having to
> > understand the semantics of all the schemas involved in the site.
> 
> > Is this clear, or should I elaborate more
> 
> Perfectly clear - you have confirmed everything I thought.  Just wanted to
> make sure!

Great.

I think XLinks are _very_ cool, but just like any other core XML
technology, rather hard to understand without working examples.

I hope that Cocoon can help people understand the whole
XLink/XPointer/XBase/XInclude "quartetto" by providing real (and very
powerful!) examples of usage.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------


Mime
View raw message