Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <3B5D7872.ECF162BB@apache.org>
Date: Tue, 24 Jul 2001 09:30:26 -0400
From: Berin Loritsch <bloritsch@apache.org>
MIME-Version: 1.0
To: cocoon-dev@xml.apache.org, Stefano Mazzocchi <stefano@apache.org>
Subject: Re: Some comments on Cocoon 2.0b2
References: <3B5D4D0C.6ACCEB32@apache.org>
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature";
 micalg=sha1; boundary="------------ms70C75965CDB8FFDA93968453"

--------------ms70C75965CDB8FFDA93968453
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Stefano Mazzocchi wrote:
> 
> I think you guys are doing a great job. From looking at the CVS commits
> and the mail logs this project has never been so healthy and I think I
> can finally say that Cocoon is a project that is going to last,
> community wise.

Good to hear from you.

> content aggregation
> -------------------
> 
> Content aggregation at sitemap level is, IMHO, limiting and imposes some
> degree of overlap between concerns.

I tend to agree.  I sent a private email to Giacomo for some ideas on
the next version of Cocoon (he's on vacation so he won't see it until
next week).  I am wanting to facilitate a better concern map (which
from using Cocoon for a while I have a better idea of how it should
be).

> An example clarifies this in detail: suppose you want to create some
> JetSpeed-like application using Cocoon2. Aggregation on the same
> resource (say '/') should depend on user identity and its preferences
> (think my.netscape.com) which might be stored someplace in a database,
> LDAP, file, memory, session, cookie, you name it.
>
> This is not possible if the aggregation controls are hardwired into the
> sitemap.

Preach it.

> It has been recently noted how there is no component that "aggregates".
> 
> Sure, you could say: ok, let's make a pluggable aggregating component to
> make this user-preferred portal possible.
> 
> Yes, that's a solution, but I believe the design mistake here is that
> "aggregation" is seen as "generation" while I see it as
> "transformation".
> 
> Suppose you have something like this:
> 
>   generator -> layout page
>   transformer -> aggregator
> 
> now you can have a generator produce the outline of the page and the
> transformer (sort of server-side XInclude for XML Inforsets) produce the
> aggregated content. The layout might use a specific namespace that is
> used to react further namespace behavior on the transformer. For example
> 
>   <lay:layout xmlns:lay="../cocoon/layout"
> xmlns:agg="../cocoon/aggregate">
>    <agg:include agg:src="hello.xml" agg:ns="http://www.blah.com"/>
>   </lay:layout>

I see. We have both the XInclude processor and the CInclude processor.
If the XInclude processor can handle the "cocoon:" protocol, we will only
need the standards based version.

> Cocoon:/ protocol
> -----------------
> 
> While I consider the concept of being able to refert to sitemap
> generated resources directly with a specific protocol very good, I
> question the necessity for the ability to access the root of the
> sitemap.
> 
> I'm still not sure myself about this, but I believe that it might lead
> to concern overlap between the different people responsible for the
> different sitemaps.

This approach is necessary many times in real development.  You can't
create a site that never has any absolute references if you have all
your images in one directory.  Just the same, you can't ensure the
entire site has the same "pipeline" if you can never refer to resources
at the root.

In your paper, you yourself addressed the problem of URLs that change.
This is no exception to that rule.

> One of the original goals of the sitemap semantics were that they must
> be fully "relocatable": this means that you can mount your sitemap on
> "/news" one day and on "/new-news" the next without having to tell the
> people responsible for the "news" sitemap.

This isn't necessarily a problem though.

> namespace-reacting trasnformations
> ----------------------------------
> 
> There are a bunch of discussions on stylebook/anakia/cocoon these days
> going on and I'm happy that Donald set up the Cocoon-By-Cocoon site
> since it gives us (finally) a serious place to show off our power.

Cocoon is also used to build the Avalon documenation written in DocBook.
There is even a Stylebook 2 DocBook conversion stylesheet in Avalon.
Talk about power....

> Now, suppose you want to generate documentation but you "don't" know in
> advance the schema used for it. All you know is that your pipeline
> expects "docbook" from some point on and you do have some "adaptation
> stylesheets" that transform these simplified but semantically equivalent
> DTDs into docbook.
> 
> So, visually, you have:
> 
>  generator -[docbook]-> transformer -[fo]-> serializer -[pdf]-> client
> 
> but if you don't know in advance the markup used you need to adapt
> 
>  generator -[???]-> adaptor -[docbook]-> ...
> 
> There are two ways to identify the semantic context of the document:
> 
> 1) DTD/Schema
> 2) namespace
> 
> In the firts case, the behavior is straightforward: depending on the
> DTD/Schema, apply a different transformation sheet.
> 
> In the second case, if the namespace used is one and only one, the same
> behavior applies. Otherwise, the writing of the stylesheets is more
> complex since it must copy over all the other tags that don't belong to
> the namespace that want to adapt.

In the example you outlined, I would tend to say, "Make a decision already!"
Writing documentation or creating a site with semantic markup requires that
the team use a standard for the site.  If you don't, you are asking for trouble
later on when you need to maintain the site.  Period.

Now, when it comes to transformers that add functionality (such as the
XIncludeTransformer, et. al.), this becomes truly important.  In Cocoon 2.1
there is an IntrospectionTransformer that will apply a transformer based on
namespace.

> Ciao.

Ciao.
--------------ms70C75965CDB8FFDA93968453
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature

MIIHuQYJKoZIhvcNAQcCoIIHqjCCB6YCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC
BbMwggKCMIIB66ADAgECAgMFCRYwDQYJKoZIhvcNAQEEBQAwgZIxCzAJBgNVBAYTAlpBMRUw
EwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhh
d3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwg
RnJlZW1haWwgUlNBIDIwMDAuOC4zMDAeFw0wMTA2MTUxNjUzMjVaFw0wMjA2MTUxNjUzMjVa
MEYxHzAdBgNVBAMTFlRoYXd0ZSBGcmVlbWFpbCBNZW1iZXIxIzAhBgkqhkiG9w0BCQEWFGJs
b3JpdHNjaEBhcGFjaGUub3JnMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDwxH1hC75i
euMrpOenvB+9dwW+gfWfdRajqlrXgYmMSDuzgWAEMW1dPs2ID7M59eZ259We5f1k7wpLOh3+
kHVTQJpqXB8PP27RKby8sA+pZdxmpTBV7LOlmFoYKNxE/Wzgu65+07TFMTreDsjDFu5R/sli
zRxfaIGQBBA/52i/lwIDAQABozEwLzAfBgNVHREEGDAWgRRibG9yaXRzY2hAYXBhY2hlLm9y
ZzAMBgNVHRMBAf8EAjAAMA0GCSqGSIb3DQEBBAUAA4GBALe83A1HaeohQl3/fjj6Rwrb3yee
wQuf0ponSJSaPsuzHbcQ+qBm6JbchGdjtetdv9O+aD1hcfmBC4n0TCmU3RfZq95OQoxgQBAm
+dcuJGZIe8VvegsP/F6wZjnvquFJsCC00uGZsUjssu0WMj7x68QbqM7xXMq3yTtj/8DZtm0y
MIIDKTCCApKgAwIBAgIBDDANBgkqhkiG9w0BAQQFADCB0TELMAkGA1UEBhMCWkExFTATBgNV
BAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMRowGAYDVQQKExFUaGF3dGUg
Q29uc3VsdGluZzEoMCYGA1UECxMfQ2VydGlmaWNhdGlvbiBTZXJ2aWNlcyBEaXZpc2lvbjEk
MCIGA1UEAxMbVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIENBMSswKQYJKoZIhvcNAQkBFhxw
ZXJzb25hbC1mcmVlbWFpbEB0aGF3dGUuY29tMB4XDTAwMDgzMDAwMDAwMFoXDTAyMDgyOTIz
NTk1OVowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENhcGUxEjAQBgNVBAcT
CUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0aWZpY2F0ZSBTZXJ2
aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAuOC4zMDCBnzANBgkq
hkiG9w0BAQEFAAOBjQAwgYkCgYEA3jMypmPHCSVFPtJueCdngcXaiBmClw7jRCmKYzUqbXA8
+tyu9+50bzC8M5B/+TRxoKNtmPHDT6Jl2w36S/HW3WGl+YXNVZo1Gp2Sdagnrthy+boC9tew
kd4c6avgGAOofENCUFGHgzzwObSbVIoTh/+zm51JZgAtCYnslGvpoWkCAwEAAaNOMEwwKQYD
VR0RBCIwIKQeMBwxGjAYBgNVBAMTEVByaXZhdGVMYWJlbDEtMjk3MBIGA1UdEwEB/wQIMAYB
Af8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBBAUAA4GBAHMbbyZli/8VNEtZYortRL5J
x+gNu4+5DWomKmKEH7iHY3QcbbfPGlORS+HN5jjZ7VD0Omw0kqzmkpxuwSMBwgmn70uuct0G
Z/VQby5YuLYLwVBXtewc1+8XttWIm7eiiBrtOVs5fTT8tpYYJU1q9J3Fw5EvqZa4BTxS/N3p
YgNIMYIBzjCCAcoCAQEwgZowgZIxCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxXZXN0ZXJuIENh
cGUxEjAQBgNVBAcTCUNhcGUgVG93bjEPMA0GA1UEChMGVGhhd3RlMR0wGwYDVQQLExRDZXJ0
aWZpY2F0ZSBTZXJ2aWNlczEoMCYGA1UEAxMfUGVyc29uYWwgRnJlZW1haWwgUlNBIDIwMDAu
OC4zMAIDBQkWMAkGBSsOAwIaBQCggYowGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkq
hkiG9w0BCQUxDxcNMDEwNzI0MTMzMDI3WjAjBgkqhkiG9w0BCQQxFgQUo4qegOv7gwuTzRIj
k6SZ5klG7sYwKwYJKoZIhvcNAQkPMR4wHDAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAw
DQYJKoZIhvcNAQEBBQAEgYDOFRy2ONkcJ1UTNguI1uTZkVxDmgwCon0Zr0rXA5jT3sGG5Yy5
ixlFGS6PMHR69AMffvxC3KlCjwEqmlza8IT46Jrp9RAL4V6GWh9c+3wB3rIs8bNn+wrDwMy2
INiOevMQrUQ16iAN2t8pyoXfZLrbhsUFuGvSu3D6O4qqDYCEKg==
--------------ms70C75965CDB8FFDA93968453--