Wider Content Management issues (was Netscape Support for XSL - client vs server rant)

Subject: Wider Content Management issues (was Netscape Support for XSL - client vs server rant)
From: Dan Morrison <dman@xxxxxxxx>
Date: Mon, 22 May 2000 21:46:32 +1200
Niclas Hedhman wrote:
> 
> Dan Morrison wrote:
> 
> > Niclas Hedhman wrote:
> > >
> > > It is absolutely clear to everyone who has been
> > > working with context separation that <?xsl-stylesheet> DOES NOT belong in the XML
> > > document at all. You are introducing styling information into content, which is
> > > wrong.
> >
> > I'm strict about function separation, but this is no more than a
> > pointer, which (IMO) is allowed into a pure data structure.
> 
> I would then construe that you are not a pure content person, but some kind of mix.

I'm anything but pure! The number of languages, styles and skills I've
had to grab at in different circumstances is bloody ridiculous!

... Then there's the work I've done with computers also...


> What if you need to change the layout in 300 out
> of the 900 documents?? 

I agree this is one of the many issues with content management systems.
Currently I approach this by using intricately cascading stylesheet
libraries, but I know I'll never be able to explain my methods to anyone
else, so I'm looking for flexible solutions. 
Abstracted, externally associated stylesheet links don't hold together
out of context of a monolithic content management system. I like my XML
to be portable, and carry their meta-data with them if possible.

(I think my coffee's too strong if I'm coming out with sentences like
the above)

How does this generic document collection know which character set to
use to display a doc? You put a small directive in it saying it's ASCII,
UTF8, Unicode or whatever. 
How does it know which form of XML to support when parsing in (there
will be changes)? You label the document with an xml version directive.
How does it know how to line the data up on a page for visual display?
You have the option to define a stylesheet to use by default.

Either this info is in some way relevant to the 'pure content' or it
isn't.

The fun bit is that your/my content management interface can override
those formatting hints and publish using whichever stylesheet we tell it
to. Or however many. 
My system has the extra option of pressing just "Display this XML" and
getting a meaningful result. It also allows me to transfer one file over
to another platform where the same thing can be done again.


> How could the content writer have the faintest idea how these
> will be organised in a wider context?

I presume your content writer has the option to choose a title, define a
few keywords, possibly even classify their content somewhat. Or do they
just fling it into the void unlabelled? Already they are influencing its
place in 'the wider context'. 

I've been lucky enough to work with content creators that _do_ have more
than the faintest idea what they're writing.
I know this talk of content context is clouding the issue when it's
content /structure/ that stylesheets are best at dealing with but...

>? He/She can not. Of that I am absolutely sure.

This is the second time you've declared yourself 'absolutely sure' about
something I'd regard as a matter of opinion.
Rhetoric like that always brings out the Devils Advocate in me.  >;-)

> I am happy when the "Management" gets control of the
> organisation and relationships between content, style and logic.

That is always an option. You've never lost that power. You just have to
think about it less.

> > The formalised xsl-stylesheet instruction, especially when qualified
> > with a media type parameter, is a very very useful hint...
>
> Again, even worse. Now the content provider has to figure out which style sheet
> belongs to each 'media'...

Only if they want to, it's all about defaults and choice. And it sort of
helps if there is SOME way for the producer to review what they've just
written. You'd get some pretty screwed results otherwise.

I just don't like the idea of losing the association between a page and
its layout into thw bowels of any propriatary management package, when
portable XML allows you to define that link right out in the open spec.
It can always be manipulated by your package, so why does you package
have to own it?


 
> The Cocoon 2 stuff goes on the cocoon-dev mailing list.

This probably explains something. As you say, I'll wait and see.

.dan.


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread