RE: [xml-dev] RE: A standard approach to glueing together reusable XML fragments in prose?

[Nordström Ari <Ari.Nordstrom@sorman.com>]

While you do get some really nice functionality with Documentum's standard XML application, if you can't, for some reason, use that and have to develop your own (in our case, the extended XLink solution we went with made using it very difficult), Documentum will serve to slow things down. You get all kinds of performance problems, especially if you have a very large docbase. 

I didn't do the actual programming so I can't give you much detail there, unfortunately. I'm not allowed to go into any specifics anyway, I think... Suffice to say that given a new Documentum-based project, I'd go to great lengths to ensure that we stick with the standard solution that's available.

/Ari

Chiusano Joseph wrote:
> 
> 
> <Quote>
> I'm not sure it was the ebst way to do it since Documentum 
> gives a whole
> bunch of problems,
> </Quote>
> 
> Care to elaborate on this?
> 
> Kind Regards,
> Joe Chiusano
> Booz | Allen | Hamilton
> 
> Nordström Ari wrote:
> > 
> > Well, the linking system hinted at in my paper, that takes 
> into account the context in which the link is published and 
> changes the generated link text accordingly, was implemented 
> in a Documentum-based CMS. I'm not sure it was the ebst way 
> to do it since Documentum gives a whole bunch of problems, 
> but it worked quite well in this case... The XML documents 
> and referenced fragments were all profiled (that is, they 
> always have a context in which they're valid), and if you 
> picked a certain profiled context when publishing (Product A, 
> B, and C, but not D, for example), the generated text in the 
> published document would change accordingly.
> > 
> > Exactly how this works takes more time and space than what 
> I have here, but for a variety of reasons we handled the 
> profiling in two ways: as attributes in checked-out 
> documents, and as link object properties in Documentum. The 
> check-in/out process translated between the two. XML 
> attributes for the profiles were very useful for processing 
> in the editing environment while the link object properties 
> gave us a nice API to toy with in Documentum, which made the 
> handling of profiles easier.
> > 
> > But also note that you can't do this unless you prepare a 
> style guide that describes how to write documents. The style 
> guide _must_ define the kind of grammatical constructs that 
> are OK when writing so that the generated text will fit in. 
> In this particular system, the source XML was translated to 
> about twenty different languages, which complicated the 
> problem enormously.
> > 
> > The original concept included means to handle standard 
> terms and phrases in text--nobody would have to use synonyms 
> or find their own ways to express common procedure steps when 
> writing--but we had to abandon that for manuals that 
> contained a lot of prose (meaning more than a few sentences 
> at any given place, maximum). This was because there was just 
> no way we could handle all of the sometimes very different 
> requirements from languages other than the source.
> > 
> > If I get a second shot at a system like this, and get to 
> actually choose the CMS, I'd probably have a look at 
> something XML-based first. TextML Server from Ixiasoft comes 
> to mind but I'm sure there are others as well.
> > 
> > Best,
> > 
> > /Ari
> > 
<snip>
>