You are viewing a plain text version of this content. The canonical link for it is here.
Posted to cvs@cocoon.apache.org by st...@locus.apache.org on 2000/06/15 23:44:40 UTC
cvs commit: xml-cocoon/xdocs/drafts sitemap-working-draft.xml
stefano 00/06/15 14:44:40
Modified: xdocs/drafts Tag: xml-cocoon2 sitemap-working-draft.xml
Log:
many changes:
- incorporated Ross' set-parameter proposal
- fixed a typo about src:jar
- added comments on <semantic-view>
- changed the root element to <sitemap> since <cocoon> will likely be somplace else
- mix typos
Please, go thru the changes and comment them at wish. Thanks.
Revision Changes Path
No revision
No revision
1.1.2.2 +64 -14 xml-cocoon/xdocs/drafts/Attic/sitemap-working-draft.xml
Index: sitemap-working-draft.xml
===================================================================
RCS file: /home/cvs/xml-cocoon/xdocs/drafts/Attic/sitemap-working-draft.xml,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- sitemap-working-draft.xml 2000/06/06 23:23:47 1.1.2.1
+++ sitemap-working-draft.xml 2000/06/15 21:44:39 1.1.2.2
@@ -44,7 +44,7 @@
==============================================================================
-This docuemnt contains an example used as a working draft for
+This document contains an example used as a working draft for
Cocoon architects to test and understand the issues associated with
sitemaps and XML publishing in general. It must be considered as a working
draft and may be updated at any time.
@@ -127,12 +127,11 @@
-->
-<cocoon xmlns="http://xml.apache.org/cocoon/config/2.0" xmlns:src="http://xml.apache.org/cocoon/loaders">
+<sitemap
+ xmlns="http://xml.apache.org/cocoon/sitemap/2.0"
+ xmlns:src="http://xml.apache.org/cocoon/loaders"
+>
- <!-- here should go Cocoon-specific parameters -->
-
- <sitemap>
-
<!-- NOTE (SM)
Components are included _inside_ the sitemap to allow cascading. This
@@ -154,6 +153,12 @@
Component ComponentManager.getComponent(String role)
-->
+
+ <!-- NOTE (SM)
+ Should we allow Avalon blocks to be accessible directly from here?
+ (this would require Block to implement Component as well)
+ -->
+
<component role="pool" src:class="org.apache.cocoon.component.DatabasePool">
<param name="max-connections">10</param>
</component>
@@ -250,8 +255,6 @@
[XXX] Should we use '$1' for both rules? or keep wildcard positioning like shown below?
- [XXX] Should we use a different namespace for the "rule" attribute, like we did for loaders?
-
-->
<!--
@@ -260,7 +263,7 @@
<mount uri="^/xerces-[j|c|p]/(.*)$" src:cvs=":pserver:anonymous@xml.apache.org:/home/cvs/xerces-$1/xdocs/$2" rule="regexp"/>
<mount uri="cocoon/*" src:cvs=":pserver:anonymous@xml.apache.org:/home/cvs/cocoon/xdocs/*"/>
<mount uri="bugs/*" src:jar="./apps/bugs.cocoon#*"/>
- <mount uri="faq/*" src:jar="jar:./apps/faq-o-matic.cocoon#*"/>
+ <mount uri="faq/*" src:jar="./apps/faq-o-matic.cocoon#*"/>
<mount uri="dist/*" src:local="./dist/*"/>
<!--
@@ -319,11 +322,42 @@
</process>
<process uri="complex-semantics/*">
- <semantic-source>
+ <semantic-view>
<generate type="parser" src:local="./complex-semantics/*"/>
<filter type="xslt" src:local="./stylesheet/rdf-izer.xsl"/>
<filter type="xslt" src:local="./stylesheet/xlink-izer.xsl"/>
- </semantic-source>
+ </semantic-view>
+ <!--
+ The semantic view should contain all the information that semantic
+ crawlers need to fully understand this resource. It normally means
+ that RDF, XLink and PI are contained in this view of the resource
+ and Cocoon will be able to interrupt the pipeline at this point
+ if the client is requesting this.
+
+ This will be used for offline crawlers, metadata indexers and
+ XML-capable browsers.
+ -->
+
+ <!-- NOTE (SM)
+
+ The semantic-view element might become too specific if the new CC/PP
+ user-agent capabilities architecture proposal is implemented. If this
+ happens, the need for multiple pipeline exit points depending on the
+ requestor capabilities will emerge. But this is clearly _way_ too
+ early to expect, anyway...
+
+ [XXX] should we define more exit points that "end" and "semantic"?
+
+ [XXX] the use of such element is not very elegant, any
+ alternative proposal?
+
+ [XXX] when called internally by the command line wrapper, Cocoon
+ will know the semantic view was called for, but when accessed
+ from the normal HTTP channels, how should Cocoon know that?
+ Should we define our own "semantic" HTTP action? would CC/PP
+ handle this as well?
+ -->
+
<if type="browser accepts text/vnd.wap.wml">
<filter type="xslt" src:local="./stylesheet/rdf2wml.xsl"/>
<serialize type="xml"/>
@@ -334,6 +368,24 @@
</else>
</process>
+ <process uri="/\([0-9]\{4\}\)/\([0-9]\{2\}\)/\([0-9]\{2\}\)/">
+ <!--
+ Here we implement the ability to indicate semantic information
+ on the processed URI. This is mostly used to avoid to encode
+ URI specific information in the XSP since the sitemap maintainer
+ is the only one responsible to manage the URI space. This removes
+ a URI contract between the XSP writer and the URI space manager,
+ moving it to parameter names which normally change less frequently.
+ -->
+ <set-parameter name="year" value="$1"/>
+ <set-parameter name="month" value="$2"/>
+ <set-parameter name="day" value="$3"/>
+
+ <generator name="serverpages" src="/dailynews.xsp">
+ <filter type="xslt" src:local="./stylesheet/news.xsl"/>
+ <serializer type="html"/>
+ </process>
+
<process uri="*">
<generate type="parser" src:local="*.xml"/>
<if test="load greater-then 2.5">
@@ -370,9 +422,7 @@
<filter type="xslt" src:local="./stylesheets/general-browser.xsl"/>
<serializer type="html" status-code="401"/>
</resource>
-
- </sitemap>
-</cocoon>
+</sitemap>
<!-- end of file -->
Re: cvs commit: xml-cocoon/xdocs/drafts sitemap-working-draft.xml
Posted by Stefano Mazzocchi <st...@apache.org>.
Ross Burton wrote:
>
> > > Maybe it's because I only got out of bed 20 minutes ago and am still
> > > asleep - but CC/PP? I'm confused... more coffee.
>
> > CC/PP -> Composite Capabilities/Preference Profiles
> > This is a very recent W3C note.
> > C'mon, people, it's the bleeding edge, you can't afford to miss anything
> > that happens on W3 :)
> > No, seriously, I'd love to see something like CC/PP happen, even if I'm
> > _seriously_ concerned about its complexity given the proposed
> > architecture requirements.
>
> It's a bit, well, huge and complex from what I have read of the spec. The
> idea is great but I think RDF is a slight overkill - the Golden Hammer
> antipattern I feel...
Well, the situation they are trying to solve is incredibly complex: how
do you express the capabilities of your user agent without creating a Mb
long HTTP request? how do you make this flexible enough to stand the
variety of user agents and devices that will emerge?
About the golden hammer.... well, RDF is a graph formalization plus a
way to serialize it using XML well-formed syntax.
When using RDF, you are simply saying
somebody ---does----> something
not much more. Then you have RDFSchema that adds
actor --- plays ---> play
(which is a person) (which is a way of performing) (which is a
performance)
this is nothing strictly related to XML, its about "describing data with
data", in short "metadata", in practice an architecture to define
"semantic networks". The XML relation is the particular XML encoding
syntax they propose, but it's clearly written that RDF could be
serialized in whatever way you find it useful (of course, since you have
XML it makes it a perfect choice for encoding syntax, even if it gets a
little verbose)
What you are doing with CC/PP is "describing the capabilities of your
user agent" so that servers (such as Cocoon) might understand what to
serve them. It's already difficult today with browsers with different
capabilities, tons of plugins, handheld devices and so on.
Consider a world where you fridge connects to the grocery store and
orders food for you.
Now, suppose that CC/PP defines a semantic network where, for example,
there are things like "SVG", "PNG", "XSL:FO".... then your IE8.0 sends
its CC/PP-encoded request indicating that it supports "Macrosplit
Formatting Object Language 4.0".
Today, if you don't know about a language, you simply can't do anything.
But if you have a semantic networks that tells you that
IE8.0 --- supports ---> "Macrosplit FOL 4.0"
(which is a desktop browser) (which is an XSL:FO
extention)
then Cocoon is able to come close enough sending FO content. Sure, it
won't be using the fancy <banner> or <blink> features that this new
language implements, but it's better than sending "sorry, don't know
what this FOL 4.0 is".
The Golden Hammer is used when you have a technology that is not well
suited for your stuff and you use it anyway because of symmetry or other
purely esthetic reasons.
Here, I see a perfect need for reusing the RDF ideas, since just like
you do with XML for parsers, an RDF-based semantic processor could be
used to extract information from documents as well as understanding what
your user agent supports.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: cvs commit: xml-cocoon/xdocs/drafts sitemap-working-draft.xml
Posted by Ross Burton <ro...@mail.com>.
> > Maybe it's because I only got out of bed 20 minutes ago and am still
> > asleep - but CC/PP? I'm confused... more coffee.
> CC/PP -> Composite Capabilities/Preference Profiles
> This is a very recent W3C note.
> C'mon, people, it's the bleeding edge, you can't afford to miss anything
> that happens on W3 :)
> No, seriously, I'd love to see something like CC/PP happen, even if I'm
> _seriously_ concerned about its complexity given the proposed
> architecture requirements.
It's a bit, well, huge and complex from what I have read of the spec. The
idea is great but I think RDF is a slight overkill - the Golden Hammer
antipattern I feel...
> Anyway, just keep up with xmlhack.com and you should be fine.
Sorry - I hadn't read it this morning!
Ross
Re: cvs commit: xml-cocoon/xdocs/drafts sitemap-working-draft.xml
Posted by Stefano Mazzocchi <st...@apache.org>.
Ross Burton wrote:
>
> > + <!-- NOTE (SM)
> > +
> > + The semantic-view element might become too specific if the new
> CC/PP
> > + user-agent capabilities architecture proposal is implemented.
> If this
> > + happens, the need for multiple pipeline exit points depending
> on the
> > + requestor capabilities will emerge. But this is clearly _way_
> too
> > + early to expect, anyway...
>
> Maybe it's because I only got out of bed 20 minutes ago and am still
> asleep - but CC/PP? I'm confused... more coffee.
CC/PP -> Composite Capabilities/Preference Profiles
This is a very recent W3C note.
C'mon, people, it's the bleeding edge, you can't afford to miss anything
that happens on W3 :)
No, seriously, I'd love to see something like CC/PP happen, even if I'm
_seriously_ concerned about its complexity given the proposed
architecture requirements.
Anyway, just keep up with xmlhack.com and you should be fine.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
Re: cvs commit: xml-cocoon/xdocs/drafts sitemap-working-draft.xml
Posted by Ross Burton <ro...@mail.com>.
> + <!-- NOTE (SM)
> +
> + The semantic-view element might become too specific if the new
CC/PP
> + user-agent capabilities architecture proposal is implemented.
If this
> + happens, the need for multiple pipeline exit points depending
on the
> + requestor capabilities will emerge. But this is clearly _way_
too
> + early to expect, anyway...
Maybe it's because I only got out of bed 20 minutes ago and am still
asleep - but CC/PP? I'm confused... more coffee.
Ross