cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Washeim <>
Subject Re: XML Query language & Site Skins
Date Thu, 17 Feb 2000 23:39:41 GMT
Ok. I think I've resolved the problem of using the sitemap, as I saw it
being a problem.

To be to the point:
Problem 1. The site map was not good means whereby authors in a shared
namespace could use each other's subset of documents
Problem 2. The site map 'appeared' to bind THE URI of a document to
'several' views, with no means of determining which view is THE model.

This problem is ameliorated (that's just to trip up the non-english speaker
for fun), I mean eased, if I proceed, as follows (I'm going to use a
Localization example because of Ulrich's earlier mention).

You'll note that nothing I'm saying is in conflict with the site-map but
extends it (or supplements it, not sure which yet).

DTDs will REQUIRE schemas. Schemas MAY be authoritative only within a target
namespace (as per the recomendation). That will permit for namespace
delimited URIs. Schemas will be extended (Derived) accross namespaces.

Ok, you can guess everything from a familiarity (I'm assuming it :) )with
the spec. 

The important this is that document authors will NOT be working against the
site-map (nor will other content managers), but against the aggregate
(composite, whatever) schema. That's perfectly congruent with Cocoon's

Since the author and manager views will NEVER be the 'public' views, the
content model will be what they work against, not views exposed through the
site map.

It will faciliItate addressing multiple doctypes accross domains with an
authoritative schema delimiting the namespaces and permiting for
permutations of document objects.

It WILL also, however, require for the public views (the more mixed up HTML
created at the direction of marketing departments) to be produced using
'producers' (generators?) that also work against the schema, but are NOT
authoritative. That is, do not have a direct relationship to the content
model namespaces. 

Since the site-map does not deal with namespaces but as if everything lived
in virtual file system, it's not a problem.

The site-map, for every public part of the document namespace, should have
ONE authritative (a la Lee) URI (in this case it will be a producer or chain
of producers, whatever) to a view and then whatever number of additional
ones that may be required.

The content managers won't be exposed to the content models in the same way
that everyone else is, however (ie, cocoon). They'll be working against the
schema (perhaps the default producer in the site-map????).

We (Large Medium) will create some mechanisms for creating producers from a
set of schemas. Perhaps in an automated way (as per the xsp compilation
mechanism??? can't remember if xsp pages are 'producers')

Stefano, remember I kept referring to a 'catalog' of entities to derive
views. What I meant but didn't explain clearly was that I wanted 'pure'
views, editors views of the content model. As you would obtain by having the
schema in front of you. Of course, we'll provide the 'affordances' of the

The following is an example in terms of content management/editing (schemas)
and cocoon site-map (derived from w3c examples):

-- Quote --
<type name="WorldAddress"
      source="po:Address" derivedBy="extension">
 <element name="country" type="string"/>

<type name="GermanAddress"
      source="po:WorldAddress" derivedBy="extension">
 <element name="land" type="string/>

<element name="person">
  . . .
  <element name="address" type="po:Address"/>


   <address xsi:type="GermanAddress">
Two types derived from the Address type defined in Sample Schema
(non-normative) (§F) are defined, adding first a country and then a land
element to its required content. Two schema-valid instances of an element
declared with type Address are shown, one using that type itself, and
therefore not requiring disambiguation, and one using the xsi:type attribute
to indicate that it is using the GermanAddress type.
-- End Quote

 <process uri="/HQAddressModel" private="true">
  <generator type="schema" src="/THESchemaNSURIWorldAddress"
   <parameter name="stylesheet" value="defaultEditor.xsl"/>
  <serializer type="HTML"/>

 <process uri="/HQAddress">
  <generator type="schema" src="THESchemaNSURIWorldAddress"/>
   <parameter name="stylesheet" value="defaultView.xsl"/>
  <serializer type="HTML"/>

 <process uri="/GermanAddressModel">
  <generator type="schema" src="THESchemaNSURIGermanAddress"/>
   <parameter name="stylesheet" value="defaultEditor.xsl"/>
  <serializer type="FO"/>

 <process uri="/GermanAddress">
  <generator type="schema" src="THESchemaNSURIGermanAddress"/>
   <parameter name="stylesheet" value="GermanView.xsl"/>
  <serializer type="HTML"/>

Ok, so far the Name spaces are all shared. However, I'm not stuck. I can use
a different target namespace for a derived schema and keep contracts and
models in tact (for the managers). For example:

 <process uri="/MarksGermanAddress">
  <generator type="schema" src="THESchemaNSURIMarksAddress"/>
   <parameter name="stylesheet" value="MarkView.xsl"/>
  <serializer type="mathML"/> (he, he, he)

Hmmm. This still needs some work, but I think the intention is clear.

I've tried to mix up the views and models, but, one thing that remains
unclear is whether you would actually use cocoon to map the namespace's for
content managers? Possibly, you just leave them out because, currently, the
post operations aren't dealt with within the frame work.???

Hmmm. Food for thought.

I'm sure it's all old hat to you guys. Please let me know what I've missed
or when I've stated the obvious.

Mark (Poetaster) Washeim

'On the linen wrappings of certain mummified remains
found near the Etrurian coast are invaluable writings
that await translation.

Quem colorem habet sapientia?'

Evan S. Connell



View raw message