You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Mark Washeim <es...@canuck.com> on 2000/02/16 22:17:27 UTC
Re: XML Query language & Site Skins
Ok, I think this may be the wrong forum for this mail but I need to start
somewhere. Stefano, please let me know if I should be contributing to the
dev dicsussion (I'm not doing development, hence user). I also know Stefano
has addressed this in part (at least from the vantage point of the
engineer). Please forgive any redundancy :) as if :)
On the whole question of Site Skins and separation of content and
presentation, I'm beginning to feel very nervous. The drift, if I'm not
mistaken is to a centralized mechanism for mapping 'views' to 'data models'.
To quote from a previous mail
---Begin Q ---
http://localhost/index.xml#news[@title=starts-with('computer')]
C'mon, do you understand how painful is to manage something like this?
URLs are things that never change. In fact a perfect web site doesn't
even specify file extentions so the above would be
http://localhost/computer-news
--- End Q---
A hypothetical fix (lifted from the mail archives)
<prefix uri="flowers">
<process uri="*.html" translate="/home/xml/*.xml">
<producer name="file" />
<processor name="xslt">
<param name="stylesheet" value="flowers.xsl" />
</processor>
<serializer name="html" />
</process>
allows us to arrive at the latter request, if I understand this correctly...
Although I agree that the 'query' type mechanism presented
(.xml#news[@title=starts-with('computer')] ) is problematic (and places
content model domain stuff in the controller's domain), the site map has
another 'ill' effect.
In fact the net effect is the same. Namely, the controller ends up mediating
something properly in the content model domain. I know, the cocoon design
will NOT be a 'naive' monolythic controller. We hope.
An example that occured to me, in the apache context, is the use, within
httpd.conf of the Redirect directive:
Redirect /oldUrl /mapToNewUrl
Ok, well, I don't really see the difference between this and a 'site map'.
In my, experience (6 years) building and maintaining sites and content
management 'systems' (usually primitive ones), this has never been an
acceptable approach.
Either it has so much centralized administration that it could only,
effectively, be done by what is tantamount to the unix superuser (read,
you'll never get a middle manager to be able to deal with this) or
management wasn't done properly at all (ie. witness all the expired redirect
directives that don't get maintained properly).
In my opinion, we should take a lesson out of the OOD domain. Namely, object
encapsulation (which, after all, does not limit polymorphism, per se). Where
URIs and Documents are concerned, I'm suggesting something like ENTITY REFs
and catalogs.
I'm thinking of an 'xsl stylesheet' in attribute terms.Of course, that
appears to break the separation of content model and view. However, first, I
don't believe most views have 'meaning' (or structure, for that matter)
without reference to the data model (not true for common awt components, but
very true of HTML). In the main, HTML is so unwieldly and what is expected
of it so demanding, that most HTML is completely 'bound' to the data model.
I know. It 'shoudn't be this way'. But it is.
I'm not suggesting we continue down that route, just acknowledge the reality
(which will obtain for several more years, at least).
I'm thinking of something like the following as an interim solution (which,
naively, appears in line with the specifications):
a 'catalog' (as in entity ref catalogs) per site
stylesheet uri's within that catalog:
---pseudo----
<!ENTITY viewStyle "viewStyleSheetURI">
<!ENTITY editStyle "editStyleSheetURI">
<!ENTITY publicViewOne "publicStyleSheetOneURI">
DTDs referencing some 'sub-set' of the catalog's stylesheets.
Withing the DTD, the following are just, more or less, arbitrary attributes
(but encapsulated).
--- pseudo---
<!ENTITY %viewStyle "catalogREF">
<!ENTITY %editStyle "catalogREF">
<!ENTITY %publicViewOne "catalogREF">
Resolving them, or using them is up to the application (controller in
question). In our (Large Medium, a web shop) context, we're building some
content management tools for our clients. We MUST account for arbitrary
document types (we attempt to introduce formality by examining proposals and
identifying overlap, before hand). We also need people in different domains
to be able to manage content independantly. Ok, the consequence? Probably
waste in terms of overlapping content models.
However, the client NEVER sees it that way (even with sophisticated IT
departments). They just want the 'functionality', the 'control'. Little do
they know, they eventually 'lose' control as they lose a centralized view of
common data stores/models. That's life.
I'm suggesting that OUR responsibility is to monitor and assist the client
in maintaining the best possible models. We can't stop them from being in a
hurry and making mistakes. We can limit the damage (including shielding
ourselves) if we do something like encapsulate, so to speak.
What it boils down to is that in some cases there will be something like a
'site map', but it won't be for the domain of all of a companies business
units, that's for certain. For example, we work for several car
manufacturers:
1. we can obtain a 'single' data model (with a lot of struggle, believe it
or not) of the specifications for an automobile
2. we cannot obtain a 'single' data model of, even, a press release (across
markets, within europe).
It shouldn't be our problem, but it does become that. So, for 1, we can have
a a number of views which simply change on the basis of context (present car
specifications as an HTML table, present an application for configuring your
'dream car' which get's it's config from the xml data store). For 2, we're
faced with a proliferation of documents. We do NOT want to manage all the
meta data (ie, which context determines which view) in house. We want the
domain expert to manage that. We can't give all the domain experts access
(or training, for that matter) in the matter of maintaining a site-wide
'skin'.
Hence, forgive the metaphor, the skin has stick to the skeleton (document,
not site).
We're trying to keep the 'coupling' loose. Namely, make applications follow
references to available views and then 'choose', NOT statically apply them.
This is precisely what cocoon does now (ie, the styelsheet reference is in
the model). This WORKS. If a business unit manager (or even an html
production person) had to make recourse to a site wide configuration, the
complexity of the task would be a pain, to say the least.
Finally, we haven't even considered the idea of 'template fragements'. Why
shouldn't I be able to use 'document fragments' and template fragments?
Oh, boy. Sorry to be so verbose. I hope this is clear. If not, I'm sure
you'll all roast me aliver :0 :)
Regards,
Mark Washeim
Technical Director
Large Medium, Critical Mass
Re: XML Query language & Site Skins
Posted by Stefano Mazzocchi <st...@apache.org>.
Mark Washeim wrote:
>
> on 18/2/2000 13.05, Stefano Mazzocchi at stefano@apache.org wrote:
>
> > Mark Washeim wrote:
> >>
> >> 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
> >> contracts.
> >>
> >> 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
> >> gui.
> >>
> >> 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>
> >>
> >> <type name="GermanAddress"
> >> source="po:WorldAddress" derivedBy="extension">
> >> <element name="land" type="string/>
> >> </type>
> >>
> >> <element name="person">
> >> <type>
> >> . . .
> >> <element name="address" type="po:Address"/>
> >> </type>
> >> </element>
> >>
> >> <person>
> >> ...
> >> <address>
> >> ...
> >> </address>
> >> </person>
> >>
> >> <person>
> >> <address xsi:type="GermanAddress">
> >> ...
> >> <country>Germany</country>
> >> <land>Saarland</land>
> >> </address>
> >> 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"
> >> <filter>
> >> <parameter name="stylesheet" value="defaultEditor.xsl"/>
> >> </filter>
> >> <serializer type="HTML"/>
> >> </process>
> >>
> >> <process uri="/HQAddress">
> >> <generator type="schema" src="THESchemaNSURIWorldAddress"/>
> >> <filter>
> >> <parameter name="stylesheet" value="defaultView.xsl"/>
> >> </filter>
> >> <serializer type="HTML"/>
> >> </process>
> >>
> >> <process uri="/GermanAddressModel">
> >> <generator type="schema" src="THESchemaNSURIGermanAddress"/>
> >> <filter>
> >> <parameter name="stylesheet" value="defaultEditor.xsl"/>
> >> </filter>
> >> <serializer type="FO"/>
> >> </process>
> >>
> >> <process uri="/GermanAddress">
> >> <generator type="schema" src="THESchemaNSURIGermanAddress"/>
> >> <filter>
> >> <parameter name="stylesheet" value="GermanView.xsl"/>
> >> </filter>
> >> <serializer type="HTML"/>
> >> </process>
> >>
> >> 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"/>
> >> <filter>
> >> <parameter name="stylesheet" value="MarkView.xsl"/>
> >> </filter>
> >> <serializer type="mathML"/> (he, he, he)
> >> </process>
> >>
> >> Hmmm. This still needs some work, but I think the intention is clear.
> >
> > Yes, I started earlier to see the light in your concerns and now I know
> > what you intended.
> >
> > I've been referring to this as "schema reaction". Meaning that the
> > pipeline is "automatically" composed by "matching" pieces... or, in a
> > sense, the pipeline could be "validated":
> >
>
> Yes, yes, yes! This is exactly where I was heading. 'Schema reaction' is
> precisely what I was thinking about. It's not just a question of validation.
> It's also a question of 'instantiation'. That is, we can only properly
> instantiate in view of the schema, not VIEWS and that's been my whole
> problem all along. The site-map appeared to limit us to creating
> producers/generators which were always views and not THE model. Ok, so we
> just introduce producers which are schema based AND, preferably, make the
> site-map 'implement' schema namespaces, perhaps within zones (as for jserv).
I think I've lost you here.
> > - generators create XML, but they _should_ inform Cocoon about what
> > namespaces they contain.
> >
>
> Yes!
>
> > - filters (I'm referring to the stylesheet itself as a filter, not the
> > XSLT processor) have consumer some namespaces and producer some others.
> >
> > - serializers consume some namespaces
> >
> > Now, think of namespaces as shapes for puzzle pieces: sometimes, you are
> > _forced_ to use one piece, or some other times, a piece can connect to
> > all others.
> >
> > Mark question can be put in this way: if we have those pieces on the
> > table, can cocoon create the puzzle without needing special
> > instructions?
> >
> > or better
> >
> > can cocoon require "less" building instructions and guess some of ouf
> > the "shape" of the pieces?
> >
>
> Yeah! Now we're surfing. Pardon the hackneyed metaphor :)
No, I like this very much myself too :)
> > Let's analyze this:
> >
> > - for puzzles, it's algorithmically certain (even if algorithimcally
> > complex), to have a turing machine that creates the puzzle only if there
> > are no pieces that have the same shape (for simplicity, I neglect the
> > picture on the pieces, I just consider their shapes) It's a matter of
> > finding the right piece but the topological analysis is trivial.
> >
> > - in the lego brick case, all pieces have the same connector shape.
> > Given a number of pieces, there is no way you can come up with the
> > wanted lego model without _detailed_ instructions.
> >
> > - for cocoon we are in between: there are some cases where one piece
> > forces the next (when one spits a schema and only one other piece is
> > able to consume it), but there are cases where a piece can connect with
> > all of the the others (the xml serializer is able to serialize _any_ xml
> > document)
> >
> > So, the question becomes: how can we use schema producting/consuming
> > information to reduce the size of the sitemap?
> >
> > I've been thinking about that since the day I started thinking about the
> > sitemap.
> >
> > I _can feel_ it's possible... I just can't see how...
> >
> > Do you have any idea?
> >
>
> I'm thinking of something as terse as (I'm just going to use paths):
> /domain/
> /domain/implementationOne/
>
> for instance:
>
> /humanresources/
> /humanresources/en/
> /humanresources/fr/
> /humanresources/fr/1999/
> /humanresources/fr/1999/datestamp
>
> ONLY the final namespace reference is to an actual document instance. The
> rest is all schema namespace.
???
> An interesting thing that comes out of this is that the namespaces, in
> addition to providing 'authority' in terms of the data model, also point
> toward a 'map' for authorization! Well, ok, I'm pushing out of the context
> of the discussion, but I'm seeing that everything until we arrive at a
> concrete document instance is obviously 'restricted'. That is, viewing it
> will be limited to within the domain of authors, content managers. That's
> interesting.
Why would you base authorization at a namespace base? I would think
about URI base authorization and authentication... not depending on
content type.
> The main point is, the 'puzzle pieces' are schema within schema. As long as
> you have a schema which contains the shared elements, a meta-schema, if you
> will, there isn't any 'real' problem assembling the puzzle. That is, because
> you actually have both the shapes of the pieces defined AND instructions for
> putting them together (the schema itself).
Hmmmm... no.
Let's consider a practical example:
1) your document is made of namespaces
a + b + z
2) you have these filters
b -> a
b -> y
b -> z
3) you have these serializers
a + z
a + y + z
a + b
possible valid pipes are
a + b + z -[b->a]-> a + z
a + b + z -[b->z]-> a + z
a + b + z -[b->y]-> a + y + z
a + b + z -[b->a]-> a + y + z
a + b + z -[b->z]-> a + y + z
all of these have significant meaning. Cocoon would not able without
some additional information to understand how this is done.
And if we put information on the next stage _inside_ the documents, we
break the separation model.
My point is: cocoon is able to see that a pipe such as
a + b + z -[b->a]-> a + b
is "illegal" since the formatter is not able to _understand_ what the
'z' namespace means and ignoring the data would be a mistake (you have
to filter it out so that you _know_ what you're doing).
But Cocoon is not able to create the pipe without attitional
information. Namespace/schema reaction is, alone, not enough.
> Of course, that's BEFORE we get to the point of a serializer or other type
> of consumer. I'll take up 'negotiating the schema' in producers, below . . .
>
> >> 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.???
> >
> > The real problem is that you have to pre-process the documents to see
> > what schema (read namespaces) they contain. And this is not always
> > possible.
> >
> > yes, we could provide some of these hooks in the
> > generator/filter/serializer API that would help to "validate" the pipe
> > and do some "sitemap debugging"... it would also help the visual sitemap
> > authoring GUIs with puzzle-like shapes that can or cannot
> > interconnect...
> >
> > Gee, I've been playing around with those ideas for months now... but I
> > can't see the light yet...
> >
>
> What I'm imaginning for the sitemap is that generators/producers (why
> generator, producer/consumer is so much clearer? generators make energy, not
> 'things' ????)
Generators are Cocoon component that implement the Producer design
pattern.
Filters are Cocoon components that implement both the producer and
consumer design patterns.
And if you have a better name we'll change it. Anyway, generator is done
to remove the problems in specifying that a filter is a producer :)
> will 'localize' to the namespace. That is, some producers,
> notably toward the 'top' of the schema, will produce by implementing schema
> derived models, others, lower in the scheme of inheritance/derivation will
> need to do some negotiation vis-a-vis the schema.
>
> Hmm. I'm starting to get fussy.
yeah
> Ok. I'm not sure that it's the correct context, but, for the sake of
> discussion, I'll stick to producers.
>
> A schema based producer would have to implement a 'SchemaNegotiator' or a
> 'SchemaNavigator'. If we return to the idea of puzzle assembling machines,
> it's obvious that what we have here is a question of indicating to the
> machine WHICH puzzle to assemble. This puzzle (schema):
>
> /humanresources/fr/1999/
>
> is easy. The machine has ALL the shapes to hand AND the instructions for
> composing the puzzle, in total.
>
> This puzzle:
>
> /humanresources/
>
> if we permit derivation by extension and restriction, we find theoretically
> of 'indefinite' (I think?) complexity. But, in practice, will it be a nicely
> finite number? Moreover, we're not necessarily asking the machine to
> assemble, only negotiate or navigate. That is, the machine must ask which
> puzzle among puzzle's to assemble.
Yes, exactly.
> If we consider a shared namespace across many document types, a schema based
> producer will have to negotiate:
>
> <type name="WorldAddress" source="po:Address" derivedBy="extension">
>
> or
>
> <address xsi:type="GermanAddress">
>
> and the complexity will make it difficult for the producer to scale with
> schema complexity, but that's not necessarily a short-term problem.
>
> Without being able to suggest a proper solution to this negotiation problem
> now, what I can suggest is that for our management/authoring problems, the
> schema based producer doesn't have to function like a Turing machine, at
> all. It only has to ask 'what puzzle do you wish me to complete' and then
> present the choices.
Right, no turing machine could do better than that anyway :)
> Of course, we have to give the schema based producer some reasonable point
> of departure. After all, many roads lead to Rome ! :)
yep, know what you're talking about :) in all senses.
> > yes, Mark, the sitemap verbosity scares me too, but I think that the
> > ways to reduce the sitemap verbosity are _not_ to be considered a design
> > flaw of the sitemap namespace or of the model of contracts... rather the
> > opposite: layering is the key. Once the sitemap is complete and it's in
> > place, we'll deal with its management costs and try to reduce them with
> > tools, xml-inheritance, xml-inclusion, xml-self-referencing and provide
> > validation points with schema reaction.
> >
> > But this, IMO, doesn't break the model, quite the opposite: it shows its
> > flexibility.
> >
> >> Hmmm. Food for thought.
> >
> > yep, hope others follow us.
> >
>
> I don't know if these primitive reflections on the use of the site-map and
> schema based production are a useful contribution. I'm entering another
> intense production period (ie. site launch in the offing), so I'm only
> skimming the surface.
>
> I do agree, as I alluded to earlier, that it's not a problem of the site-map
> per se. Just a question of attending to distinction between:
>
> Model (DTD or Schema) on the one hand, and
> Implementation (XML document instance) on the other.????
>
> >> I'm sure it's all old hat to you guys.
> >
> > No, really, it helped to me clarify things that were still blurry in my
> > head.
> >
> >> Please let me know what I've missed or when I've stated the obvious.
> >
> > What you've stated is _far_ from obvious, expecially since a vision of
> > orthogonal namespaces is missing even inside the XML spec. The XSchema
> > people are trying to patch the design flaws of the XML 1.0 spec... but
> > it will take some time before people start to understand what XML is
> > really about: namespaces.
> >
>
> It wasn't obvious to me, initially. I, like everyone else was busy thinking
> about the fact that the data model representation at the level of the
> individual model was finally being addressed. I'm propelled to think beyond
> that because we already have to consider: many clients, many client/domains.
> I guess the pressure to encompass that complexity brings the namespace
> issues to the forefront.
>
> The other thing which prompted me was looking at the jserv zone based
> preferences model and the use of aliases for servlet initialization.
>
> In our case, we have something very much like the site-map approach in place
> for servlets.
>
> We have, in reality only ONE servlet (LMServlet) which is always intialized
> with a set of ACTIONS. These actions implement a wrapper (or decorator)
> pattern, hence, may be wrapped around one another in an, almost, arbitrary
> order. The long and the short of it is that we minimize the the
> administration to the central locale of the domain.properties file. Looks
> like this in the file:
>
> servlet 1
> servlet.someAlias.code=LMServlet
> servlet.someAlias.initArgs=ACTIONS=lm.saw.LogAction;lm.saw.SendTemplateActio
> n;lm.client.domain.saw.someBusinessLogicAction;lm.saw.SIDAction,LOGFILE=/som
> e/path/somelog.log,LOGFIELDS=SEC;PG,SOME_TABLE=someTable,ALIAS=someAlias
>
> servlet 2
> servlet.someAlias2.code=LMServlet
> servlet.someAlias2.initArgs=ACTIONS=lm.saw.LogAction;lm.saw.SendTemplateActi
> on;lm.client.domain.saw.someOtherBusinessLogicAction;lm.saw.SIDAction,LOGFIL
> E=/some/path/somelog2.log,LOGFIELDS=SEC;PG,SOME_TABLE=someTable,ALIAS=someAl
> ias2
>
> Like cocoon (sort of), LMServlet is just a framework and like the sitemap,
> we use the domain.properties file to simplify administration of the servlets
> in the system. And, as you point out for the site-map in cocoon, this does
> scale well.
>
> Anyway, the main point is that the process directives in the site-map,
> mapping producers, filters and serializers is similar to this, but more
> complex.
>
> Ok, I'm drifting off topic, I think. ....
>
> >> Quem colorem habet sapientia?'
> >
> > Hmmmm, blue cocoon? :)
>
> I think blue is definitely the right colour. I may be able to contribute a
> graphic designer to do some logo design. Any one else volunteered yet???
We already have a new one that will go on the fancy long-sleeved
t-shirts (m-shirts?) that Pier is preparing.
Checkout the new logo under the "xml-cocoon2" branch of the CVS.
Thanks anyway, but keep your guys focused on creating those development
tools :)
Gee, I'd really love to have visual administration tools for Cocoon. I'd
scream for them...
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: XML Query language & Site Skins
Posted by Mark Washeim <es...@canuck.com>.
on 18/2/2000 13.05, Stefano Mazzocchi at stefano@apache.org wrote:
> Mark Washeim wrote:
>>
>> 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
>> contracts.
>>
>> 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
>> gui.
>>
>> 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>
>>
>> <type name="GermanAddress"
>> source="po:WorldAddress" derivedBy="extension">
>> <element name="land" type="string/>
>> </type>
>>
>> <element name="person">
>> <type>
>> . . .
>> <element name="address" type="po:Address"/>
>> </type>
>> </element>
>>
>> <person>
>> ...
>> <address>
>> ...
>> </address>
>> </person>
>>
>> <person>
>> <address xsi:type="GermanAddress">
>> ...
>> <country>Germany</country>
>> <land>Saarland</land>
>> </address>
>> 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"
>> <filter>
>> <parameter name="stylesheet" value="defaultEditor.xsl"/>
>> </filter>
>> <serializer type="HTML"/>
>> </process>
>>
>> <process uri="/HQAddress">
>> <generator type="schema" src="THESchemaNSURIWorldAddress"/>
>> <filter>
>> <parameter name="stylesheet" value="defaultView.xsl"/>
>> </filter>
>> <serializer type="HTML"/>
>> </process>
>>
>> <process uri="/GermanAddressModel">
>> <generator type="schema" src="THESchemaNSURIGermanAddress"/>
>> <filter>
>> <parameter name="stylesheet" value="defaultEditor.xsl"/>
>> </filter>
>> <serializer type="FO"/>
>> </process>
>>
>> <process uri="/GermanAddress">
>> <generator type="schema" src="THESchemaNSURIGermanAddress"/>
>> <filter>
>> <parameter name="stylesheet" value="GermanView.xsl"/>
>> </filter>
>> <serializer type="HTML"/>
>> </process>
>>
>> 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"/>
>> <filter>
>> <parameter name="stylesheet" value="MarkView.xsl"/>
>> </filter>
>> <serializer type="mathML"/> (he, he, he)
>> </process>
>>
>> Hmmm. This still needs some work, but I think the intention is clear.
>
> Yes, I started earlier to see the light in your concerns and now I know
> what you intended.
>
> I've been referring to this as "schema reaction". Meaning that the
> pipeline is "automatically" composed by "matching" pieces... or, in a
> sense, the pipeline could be "validated":
>
Yes, yes, yes! This is exactly where I was heading. 'Schema reaction' is
precisely what I was thinking about. It's not just a question of validation.
It's also a question of 'instantiation'. That is, we can only properly
instantiate in view of the schema, not VIEWS and that's been my whole
problem all along. The site-map appeared to limit us to creating
producers/generators which were always views and not THE model. Ok, so we
just introduce producers which are schema based AND, preferably, make the
site-map 'implement' schema namespaces, perhaps within zones (as for jserv).
> - generators create XML, but they _should_ inform Cocoon about what
> namespaces they contain.
>
Yes!
> - filters (I'm referring to the stylesheet itself as a filter, not the
> XSLT processor) have consumer some namespaces and producer some others.
>
> - serializers consume some namespaces
>
> Now, think of namespaces as shapes for puzzle pieces: sometimes, you are
> _forced_ to use one piece, or some other times, a piece can connect to
> all others.
>
> Mark question can be put in this way: if we have those pieces on the
> table, can cocoon create the puzzle without needing special
> instructions?
>
> or better
>
> can cocoon require "less" building instructions and guess some of ouf
> the "shape" of the pieces?
>
Yeah! Now we're surfing. Pardon the hackneyed metaphor :)
> Let's analyze this:
>
> - for puzzles, it's algorithmically certain (even if algorithimcally
> complex), to have a turing machine that creates the puzzle only if there
> are no pieces that have the same shape (for simplicity, I neglect the
> picture on the pieces, I just consider their shapes) It's a matter of
> finding the right piece but the topological analysis is trivial.
>
> - in the lego brick case, all pieces have the same connector shape.
> Given a number of pieces, there is no way you can come up with the
> wanted lego model without _detailed_ instructions.
>
> - for cocoon we are in between: there are some cases where one piece
> forces the next (when one spits a schema and only one other piece is
> able to consume it), but there are cases where a piece can connect with
> all of the the others (the xml serializer is able to serialize _any_ xml
> document)
>
> So, the question becomes: how can we use schema producting/consuming
> information to reduce the size of the sitemap?
>
> I've been thinking about that since the day I started thinking about the
> sitemap.
>
> I _can feel_ it's possible... I just can't see how...
>
> Do you have any idea?
>
I'm thinking of something as terse as (I'm just going to use paths):
/domain/
/domain/implementationOne/
for instance:
/humanresources/
/humanresources/en/
/humanresources/fr/
/humanresources/fr/1999/
/humanresources/fr/1999/datestamp
ONLY the final namespace reference is to an actual document instance. The
rest is all schema namespace.
An interesting thing that comes out of this is that the namespaces, in
addition to providing 'authority' in terms of the data model, also point
toward a 'map' for authorization! Well, ok, I'm pushing out of the context
of the discussion, but I'm seeing that everything until we arrive at a
concrete document instance is obviously 'restricted'. That is, viewing it
will be limited to within the domain of authors, content managers. That's
interesting.
The main point is, the 'puzzle pieces' are schema within schema. As long as
you have a schema which contains the shared elements, a meta-schema, if you
will, there isn't any 'real' problem assembling the puzzle. That is, because
you actually have both the shapes of the pieces defined AND instructions for
putting them together (the schema itself).
Of course, that's BEFORE we get to the point of a serializer or other type
of consumer. I'll take up 'negotiating the schema' in producers, below . . .
>> 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.???
>
> The real problem is that you have to pre-process the documents to see
> what schema (read namespaces) they contain. And this is not always
> possible.
>
> yes, we could provide some of these hooks in the
> generator/filter/serializer API that would help to "validate" the pipe
> and do some "sitemap debugging"... it would also help the visual sitemap
> authoring GUIs with puzzle-like shapes that can or cannot
> interconnect...
>
> Gee, I've been playing around with those ideas for months now... but I
> can't see the light yet...
>
What I'm imaginning for the sitemap is that generators/producers (why
generator, producer/consumer is so much clearer? generators make energy, not
'things' ????) will 'localize' to the namespace. That is, some producers,
notably toward the 'top' of the schema, will produce by implementing schema
derived models, others, lower in the scheme of inheritance/derivation will
need to do some negotiation vis-a-vis the schema.
Hmm. I'm starting to get fussy.
Ok. I'm not sure that it's the correct context, but, for the sake of
discussion, I'll stick to producers.
A schema based producer would have to implement a 'SchemaNegotiator' or a
'SchemaNavigator'. If we return to the idea of puzzle assembling machines,
it's obvious that what we have here is a question of indicating to the
machine WHICH puzzle to assemble. This puzzle (schema):
/humanresources/fr/1999/
is easy. The machine has ALL the shapes to hand AND the instructions for
composing the puzzle, in total.
This puzzle:
/humanresources/
if we permit derivation by extension and restriction, we find theoretically
of 'indefinite' (I think?) complexity. But, in practice, will it be a nicely
finite number? Moreover, we're not necessarily asking the machine to
assemble, only negotiate or navigate. That is, the machine must ask which
puzzle among puzzle's to assemble.
If we consider a shared namespace across many document types, a schema based
producer will have to negotiate:
<type name="WorldAddress" source="po:Address" derivedBy="extension">
or
<address xsi:type="GermanAddress">
and the complexity will make it difficult for the producer to scale with
schema complexity, but that's not necessarily a short-term problem.
Without being able to suggest a proper solution to this negotiation problem
now, what I can suggest is that for our management/authoring problems, the
schema based producer doesn't have to function like a Turing machine, at
all. It only has to ask 'what puzzle do you wish me to complete' and then
present the choices.
Of course, we have to give the schema based producer some reasonable point
of departure. After all, many roads lead to Rome ! :)
> yes, Mark, the sitemap verbosity scares me too, but I think that the
> ways to reduce the sitemap verbosity are _not_ to be considered a design
> flaw of the sitemap namespace or of the model of contracts... rather the
> opposite: layering is the key. Once the sitemap is complete and it's in
> place, we'll deal with its management costs and try to reduce them with
> tools, xml-inheritance, xml-inclusion, xml-self-referencing and provide
> validation points with schema reaction.
>
> But this, IMO, doesn't break the model, quite the opposite: it shows its
> flexibility.
>
>> Hmmm. Food for thought.
>
> yep, hope others follow us.
>
I don't know if these primitive reflections on the use of the site-map and
schema based production are a useful contribution. I'm entering another
intense production period (ie. site launch in the offing), so I'm only
skimming the surface.
I do agree, as I alluded to earlier, that it's not a problem of the site-map
per se. Just a question of attending to distinction between:
Model (DTD or Schema) on the one hand, and
Implementation (XML document instance) on the other.????
>> I'm sure it's all old hat to you guys.
>
> No, really, it helped to me clarify things that were still blurry in my
> head.
>
>> Please let me know what I've missed or when I've stated the obvious.
>
> What you've stated is _far_ from obvious, expecially since a vision of
> orthogonal namespaces is missing even inside the XML spec. The XSchema
> people are trying to patch the design flaws of the XML 1.0 spec... but
> it will take some time before people start to understand what XML is
> really about: namespaces.
>
It wasn't obvious to me, initially. I, like everyone else was busy thinking
about the fact that the data model representation at the level of the
individual model was finally being addressed. I'm propelled to think beyond
that because we already have to consider: many clients, many client/domains.
I guess the pressure to encompass that complexity brings the namespace
issues to the forefront.
The other thing which prompted me was looking at the jserv zone based
preferences model and the use of aliases for servlet initialization.
In our case, we have something very much like the site-map approach in place
for servlets.
We have, in reality only ONE servlet (LMServlet) which is always intialized
with a set of ACTIONS. These actions implement a wrapper (or decorator)
pattern, hence, may be wrapped around one another in an, almost, arbitrary
order. The long and the short of it is that we minimize the the
administration to the central locale of the domain.properties file. Looks
like this in the file:
servlet 1
servlet.someAlias.code=LMServlet
servlet.someAlias.initArgs=ACTIONS=lm.saw.LogAction;lm.saw.SendTemplateActio
n;lm.client.domain.saw.someBusinessLogicAction;lm.saw.SIDAction,LOGFILE=/som
e/path/somelog.log,LOGFIELDS=SEC;PG,SOME_TABLE=someTable,ALIAS=someAlias
servlet 2
servlet.someAlias2.code=LMServlet
servlet.someAlias2.initArgs=ACTIONS=lm.saw.LogAction;lm.saw.SendTemplateActi
on;lm.client.domain.saw.someOtherBusinessLogicAction;lm.saw.SIDAction,LOGFIL
E=/some/path/somelog2.log,LOGFIELDS=SEC;PG,SOME_TABLE=someTable,ALIAS=someAl
ias2
Like cocoon (sort of), LMServlet is just a framework and like the sitemap,
we use the domain.properties file to simplify administration of the servlets
in the system. And, as you point out for the site-map in cocoon, this does
scale well.
Anyway, the main point is that the process directives in the site-map,
mapping producers, filters and serializers is similar to this, but more
complex.
Ok, I'm drifting off topic, I think. ....
>> Quem colorem habet sapientia?'
>
> Hmmmm, blue cocoon? :)
I think blue is definitely the right colour. I may be able to contribute a
graphic designer to do some logo design. Any one else volunteered yet???
--
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
Re: XML Query language & Site Skins
Posted by Stefano Mazzocchi <st...@apache.org>.
Mark Washeim wrote:
>
> 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
> contracts.
>
> 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
> gui.
>
> 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>
>
> <type name="GermanAddress"
> source="po:WorldAddress" derivedBy="extension">
> <element name="land" type="string/>
> </type>
>
> <element name="person">
> <type>
> . . .
> <element name="address" type="po:Address"/>
> </type>
> </element>
>
> <person>
> ...
> <address>
> ...
> </address>
> </person>
>
> <person>
> <address xsi:type="GermanAddress">
> ...
> <country>Germany</country>
> <land>Saarland</land>
> </address>
> 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"
> <filter>
> <parameter name="stylesheet" value="defaultEditor.xsl"/>
> </filter>
> <serializer type="HTML"/>
> </process>
>
> <process uri="/HQAddress">
> <generator type="schema" src="THESchemaNSURIWorldAddress"/>
> <filter>
> <parameter name="stylesheet" value="defaultView.xsl"/>
> </filter>
> <serializer type="HTML"/>
> </process>
>
> <process uri="/GermanAddressModel">
> <generator type="schema" src="THESchemaNSURIGermanAddress"/>
> <filter>
> <parameter name="stylesheet" value="defaultEditor.xsl"/>
> </filter>
> <serializer type="FO"/>
> </process>
>
> <process uri="/GermanAddress">
> <generator type="schema" src="THESchemaNSURIGermanAddress"/>
> <filter>
> <parameter name="stylesheet" value="GermanView.xsl"/>
> </filter>
> <serializer type="HTML"/>
> </process>
>
> 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"/>
> <filter>
> <parameter name="stylesheet" value="MarkView.xsl"/>
> </filter>
> <serializer type="mathML"/> (he, he, he)
> </process>
>
> Hmmm. This still needs some work, but I think the intention is clear.
Yes, I started earlier to see the light in your concerns and now I know
what you intended.
I've been referring to this as "schema reaction". Meaning that the
pipeline is "automatically" composed by "matching" pieces... or, in a
sense, the pipeline could be "validated":
- generators create XML, but they _should_ inform Cocoon about what
namespaces they contain.
- filters (I'm referring to the stylesheet itself as a filter, not the
XSLT processor) have consumer some namespaces and producer some others.
- serializers consume some namespaces
Now, think of namespaces as shapes for puzzle pieces: sometimes, you are
_forced_ to use one piece, or some other times, a piece can connect to
all others.
Mark question can be put in this way: if we have those pieces on the
table, can cocoon create the puzzle without needing special
instructions?
or better
can cocoon require "less" building instructions and guess some of ouf
the "shape" of the pieces?
Let's analyze this:
- for puzzles, it's algorithmically certain (even if algorithimcally
complex), to have a turing machine that creates the puzzle only if there
are no pieces that have the same shape (for simplicity, I neglect the
picture on the pieces, I just consider their shapes) It's a matter of
finding the right piece but the topological analysis is trivial.
- in the lego brick case, all pieces have the same connector shape.
Given a number of pieces, there is no way you can come up with the
wanted lego model without _detailed_ instructions.
- for cocoon we are in between: there are some cases where one piece
forces the next (when one spits a schema and only one other piece is
able to consume it), but there are cases where a piece can connect with
all of the the others (the xml serializer is able to serialize _any_ xml
document)
So, the question becomes: how can we use schema producting/consuming
information to reduce the size of the sitemap?
I've been thinking about that since the day I started thinking about the
sitemap.
I _can feel_ it's possible... I just can't see how...
Do you have any idea?
> 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.???
The real problem is that you have to pre-process the documents to see
what schema (read namespaces) they contain. And this is not always
possible.
yes, we could provide some of these hooks in the
generator/filter/serializer API that would help to "validate" the pipe
and do some "sitemap debugging"... it would also help the visual sitemap
authoring GUIs with puzzle-like shapes that can or cannot
interconnect...
Gee, I've been playing around with those ideas for months now... but I
can't see the light yet...
yes, Mark, the sitemap verbosity scares me too, but I think that the
ways to reduce the sitemap verbosity are _not_ to be considered a design
flaw of the sitemap namespace or of the model of contracts... rather the
opposite: layering is the key. Once the sitemap is complete and it's in
place, we'll deal with its management costs and try to reduce them with
tools, xml-inheritance, xml-inclusion, xml-self-referencing and provide
validation points with schema reaction.
But this, IMO, doesn't break the model, quite the opposite: it shows its
flexibility.
> Hmmm. Food for thought.
yep, hope others follow us.
> I'm sure it's all old hat to you guys.
No, really, it helped to me clarify things that were still blurry in my
head.
> Please let me know what I've missed or when I've stated the obvious.
What you've stated is _far_ from obvious, expecially since a vision of
orthogonal namespaces is missing even inside the XML spec. The XSchema
people are trying to patch the design flaws of the XML 1.0 spec... but
it will take some time before people start to understand what XML is
really about: namespaces.
> Quem colorem habet sapientia?'
Hmmmm, blue cocoon? :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: XML Query language & Site Skins
Posted by Mark Washeim <es...@canuck.com>.
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
contracts.
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
gui.
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>
<type name="GermanAddress"
source="po:WorldAddress" derivedBy="extension">
<element name="land" type="string/>
</type>
<element name="person">
<type>
. . .
<element name="address" type="po:Address"/>
</type>
</element>
<person>
...
<address>
...
</address>
</person>
<person>
<address xsi:type="GermanAddress">
...
<country>Germany</country>
<land>Saarland</land>
</address>
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"
<filter>
<parameter name="stylesheet" value="defaultEditor.xsl"/>
</filter>
<serializer type="HTML"/>
</process>
<process uri="/HQAddress">
<generator type="schema" src="THESchemaNSURIWorldAddress"/>
<filter>
<parameter name="stylesheet" value="defaultView.xsl"/>
</filter>
<serializer type="HTML"/>
</process>
<process uri="/GermanAddressModel">
<generator type="schema" src="THESchemaNSURIGermanAddress"/>
<filter>
<parameter name="stylesheet" value="defaultEditor.xsl"/>
</filter>
<serializer type="FO"/>
</process>
<process uri="/GermanAddress">
<generator type="schema" src="THESchemaNSURIGermanAddress"/>
<filter>
<parameter name="stylesheet" value="GermanView.xsl"/>
</filter>
<serializer type="HTML"/>
</process>
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"/>
<filter>
<parameter name="stylesheet" value="MarkView.xsl"/>
</filter>
<serializer type="mathML"/> (he, he, he)
</process>
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
Re: XML Query language & Site Skins
Posted by Stefano Mazzocchi <st...@apache.org>.
Thomas Yip wrote:
>
> > The least complicated solution I see is an "intelligent" processor which
> > would attempt to assign site-defined tag names to block level elements
> > according to rules defined in an auxiliary XML file. Anyone up for a
> little
> > AI?
>
> Well, I know it is totally out of topic.
> But, I must exclaim that the biggest disappointment about computer science
> during my four years university life was about artificial intelligence:
> AI does not do *any* smart things. The programmer basically design an
> algorithm
> which return a value from a state of the game. And, what AI does is use
> something
> *slightly* better than "brute-force search" to serach some or all the
> possible states
> and report the biggest value it find.
>
> If you're a computer, and if you're assigned to do gui, you're a sales;
> if you're assigned to do email, you're a messager;
> and if you're assigned to do AI, you're a cheap labour.
>
> We have AI because we don't want to do the dumb thing ourself.
> Don't expect smart things come out from AI.
>
> Well, it's not AI people's fault. It's what happen if you ask
> an age of three to be a politician.(well, although they maybe
> already better than the one in your country)
> They simply can't do better.
>
> Sorry, for totally out of topic. Just try to find a way to release
> my disappointments...... :-(
Very interesting vision.
Have you ever read Alan Turing's master thesis? He speculates that
intelligence is, to use my own words, a noisy turing machine. He uses a
black box to indicate that it's not deterministic what happens in there,
but he doesn't add particular qualities to that stocastic process.
In a sense, a turing machine cannot be smart: it simply follows
instructions.
Marvin Minsky in his long fight against connectionists (those who
believe in neural networks as the only way to create real intelligence)
showed that a neuron can be modelled with a turing machine. So, 1 + 1 =
2: a brain is a collection of neurons... so it's just a bigger turing
machine.
This created all the "expert system" bullshit: given enough memory,
processign power and resources, a program can learn and "see the world".
There is a project somewhere where people continously feed data into a
computer program and they've been doing this for 10 years!!! They think
it's just a matter of time and complexity and amount of data.
I wish them luck.
Noise is the very base of all physical processes. Any theory that
doesn't account for noise (both social, economical and biological) is
born dead or fails into the "proof of concept" range.
OpenSource, in a sense, it's a way to "shape noise" into a specific
direction. Against all social thermodynamics principles known before.
What an interesting period of the history of mankind to live :)
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------
Re: XML Query language & Site Skins
Posted by Thomas Yip <ty...@yahoo.com>.
> The least complicated solution I see is an "intelligent" processor which
> would attempt to assign site-defined tag names to block level elements
> according to rules defined in an auxiliary XML file. Anyone up for a
little
> AI?
Well, I know it is totally out of topic.
But, I must exclaim that the biggest disappointment about computer science
during my four years university life was about artificial intelligence:
AI does not do *any* smart things. The programmer basically design an
algorithm
which return a value from a state of the game. And, what AI does is use
something
*slightly* better than "brute-force search" to serach some or all the
possible states
and report the biggest value it find.
If you're a computer, and if you're assigned to do gui, you're a sales;
if you're assigned to do email, you're a messager;
and if you're assigned to do AI, you're a cheap labour.
We have AI because we don't want to do the dumb thing ourself.
Don't expect smart things come out from AI.
Well, it's not AI people's fault. It's what happen if you ask
an age of three to be a politician.(well, although they maybe
already better than the one in your country)
They simply can't do better.
Sorry, for totally out of topic. Just try to find a way to release
my disappointments...... :-(
Re: XML Query language & Site Skins
Posted by Ed Knutson <ed...@webcombo.net>.
> But careful: Cocoon is not the solution for everybody. I do see the need
> for HTML and Cocoon will provide some HTML -> XML adapters (using JTidy)
> that would allow you to strip style from HTML and use them as content
> containers... then apply your site styles using XSLT.
I am in that exact situation. However, because my site does not use much
style outside the body tag except for <font> and has a consistent, table
layout, I am developing a class to be used by XSP which will find the cell
in the table that customarily contains the content and return it verbatim as
text. I also have the luxury, for now, to assume that every request will be
for HTML.
The question is, how do you use your site styles on generic HTML? XSL seems
to rely on templates which match certain tags. If all I had was "raw"
XHTML, my stylesheet would append it, unformatted, at the end of an
"apply-templates" term.
The least complicated solution I see is an "intelligent" processor which
would attempt to assign site-defined tag names to block level elements
according to rules defined in an auxiliary XML file. Anyone up for a little
AI?
-ed
Re: XML Query language & Site Skins
Posted by Stefano Mazzocchi <st...@apache.org>.
Mark Washeim wrote:
[...]
> We're trying to keep the 'coupling' loose. Namely, make applications follow
> references to available views and then 'choose', NOT statically apply them.
> This is precisely what cocoon does now (ie, the styelsheet reference is in
> the model). This WORKS. If a business unit manager (or even an html
> production person) had to make recourse to a site wide configuration, the
> complexity of the task would be a pain, to say the least.
I hear you and I totally understand your concern. On the other hand,
layering is the key: the sitemap provides control over everything. A
central point of management... but this doesn't mean it's a single
file... or even that is an XML file to edit with a text editor!
Like apache uses .htaccess files to add special directory
configurations, so will Cocoon at one point.
The question is: should the content owner has the right to decide what
style to apply directly from the content?
I say no. No matter what.
Why? because this is less expensive at first, but much more expensive at
the end. Think about creating a Xmas view of your web site... how do you
change that? you go into every file? how do you force them to use the
DTDs you want them to use if everyone can come up with their own DTD and
make their own stylesheet?
Is this any different than HTML? no.
Cocoon doesn't remove the possibility for you to use HTML as you did
before... or even mix it with whatever web technology you liked in the
past or you are forced to use. But gives you new guidelines. And this
_require_ some business practices that might be expensive at first...
but pay off in the long run.
But careful: Cocoon is not the solution for everybody. I do see the need
for HTML and Cocoon will provide some HTML -> XML adapters (using JTidy)
that would allow you to strip style from HTML and use them as content
containers... then apply your site styles using XSLT.
I see this as a good compromise when HTML-ish business practices are too
radicated to mutate in the short term... but the model of reduced
contracts works. I do believe in that.
> Finally, we haven't even considered the idea of 'template fragements'. Why
> shouldn't I be able to use 'document fragments' and template fragments?
That's totally different story... browse thru the general@xml.apache.org
archives and look for my proposals for X-Inheritance, the proposal to
add inheritance capabilities to XML.
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Come to the first official Apache Software Foundation Conference!
------------------------- http://ApacheCon.Com ---------------------