hi, >The idea sounds excellent Berni. Would you please >explain a little more about how you see this >process working. Is it ... > >UML (model of a particular sitemap instance) > | >XMI (interchange of model via XML) > | >XSLT (xmi2sitemap.xsl) > | >XML (the sitemap.xmap instance) > >The Cocoon sitemap probably *is* the model, >as you say. However, it can be modelled using >something else and then represented as a Sitemap. > > that's already a solution, The challenge is to define the UML, UML is very general, As the current UML tools allows you define any kind of classes. But we have already Cocoon which defines the runtime behaviour of our model, already.
>I probably display ignorance, but who cares if it >leads to something useful. I went googling a came >across a reliable starting point: > Conceptual Modeling and Markup Languages > http://xml.coverpages.org/conceptualModeling.html > > Thanks for your response, you presented already the solution, i checked your link, too, thx for the "conceptual modelling" hint, i tried to be a bit more specific about my ideas, comments are very welcome Conceptual Modelling A WebSite A model for modelling a web site, the model should describe a web site using UML. The model should help managing a web site using Cocoon. The model should generate some, or all Cocoon configuration files especially the sitemap.xmap files of the cocoon hosted website. Keywords uri space - names for accessing resources, documents of a website document - some sort of content accessible from the website sitemap - mapping rules from the "virtual" uri space to some physical space, eg. filesystem names, application names, etc. Identifying design patterns Identifying design patterns in the sitemap helps communicating about realizing the model of a website using Cocoon. As a result we may find that some requirements of a website * implemented in the sitemap * implemented in some sitemap object, like generator, transformer, etc. * scattered around in more than one spot in the sitemap As a long term result we may yield a sitemap metric. Design Pattern Catalogue As a starting point I'd like to introduce some design patterns identified so far in cocoon sitemaps. The examples are taken from the forrest sitemap. Introducing these design patterns into the Cocoon's context should help to understand and manage Cocoon's sitemap more easily. These design patterns are an abstraction of Cocoon's sitemap objects. The naming of the design patterns are used from the GoF Design Patterns book. * Resource The overall abstraction of all classes of the sitemap model. * XMLDocumentResource, XSLTDocumentResource Leaf classes of the sitemap model, there is a 1:1 mapping to physical resources * AbstractComposite A composition of a resource, AbstractBuilder, AbstractDecorator, AbstractProxy are inherited from this abstraction. * AbstractBuilder, MenuBuilder, AggregateBuilder, DocumentBuilder A builder of some resource, it abstracts the processing of some resource, the result of this processing is the product of the builder, the result of a builder is a resource * AbstractDecorator, SkinningDecorator An augmentation of resource * AbstractProxy, AssociationProxy, MatchingProxy, SelectorProxy Abstraction of some sort of mapping from a source to a resource A Sitemap Modeller Tool Finally I like to give some pratical usage of the above described design patterns. As of today UML Tool are used for modelling systems, and generating some programming language code. Now in the Cocoon context the 'language code' should be the sitmap xml document. The classes modelled in an UML tool might use directly sitemap elements, moreover the design patterns, described above. Hence as a website manager you don't have to add classes to the UML model, but you might add desing pattern which are an abstraction of one ore more cocoon elements. Editing cocoon's sitemap means editing the object diagram of the UML Tool. Collaboration, and Sequence diagramms should be auto-generatable as the dynamic behaviour of the sitemap model is already defined by the Cocoon implementation. Case Study Forrest site The following section describes the forrest site, identifying assumptions, and requirements. Moreover I try to identify patterns in the sitemap for implementing the assumptions and requirements. HTML documents are mapped to files with extension .html. PDF documents are mapped to file having extension .pdf. Images are mapped to file having extension .gif, .jpg, and .png, residing in directory images. The skinning of the forrest web site is defined in the skin directory, and consists of javascript files, css files, and images files in the images directory. The filesystem and uri space layout has following tree structure: / +---skin | /---images +---images +---community | /---howto | +---v10 | +---xmlform | +---bugzilla-patch | | /---my-images | /---cvs-ssh +---xml-site | /---xml-site /---howto /---xmlform Uri space patterns 1. Each document has a html, and a pdf form, residing in the same directory, the html document has the extension .html, the pdf document variant has the extension .pdf. 2. Images, skin information reside in forrest web site global directory image, and skin. As this date is shared by all web pages centeralizing these resources helps browsers caching these info, and reducing resource consumption, on the server, and client side. Consequences of the uri space patterns The uri space patterns above have consequences defining the cocoon sitemap.xmap. There are matching rules for uri-pattern of the form like '*.pdf' for generating pdf documents. There are matching rules for uri-pattern of the form like '*.html' for generating html documents. Centeralized resources for images, javascript, css etc are never relative to the current document, but always relative to the context-root of the site. This allows documents to share images, reducing bandwidth, and allowing proxy and browser to cache resources. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
