OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] RE: A standard approach to glueing together reusable XML

[ Lists Home | Date Index | Thread Index ]
  • To: "Chiusano Joseph" <chiusano_joseph@bah.com>
  • Subject: RE: [xml-dev] RE: A standard approach to glueing together reusable XML fragments in prose?
  • From: Nordström Ari <Ari.Nordstrom@sorman.com>
  • Date: Wed, 20 Aug 2003 12:54:50 +0200
  • Cc: <xml-dev@lists.xml.org>
  • Thread-index: AcNnCXnge42/lEkiQli8k33mYIkM8Q==
  • Thread-topic: [xml-dev] RE: A standard approach to glueing together reusable XML fragments in prose?

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



Chiusano Joseph wrote:
> 
> 
> Can you describe how an XML registy/repository helped/could help your
> work?
> 
> Kind Regards,
> Joe Chiusano
> Booz | Allen | Hamilton
> 
> Nordström Ari wrote:
> > 
> > Hi,
> > 
> > These are very interesting questions. And as you may have 
> noted, there are some interesting problems associated as well. :-)
> > 
> > For one, the simple problem of presenting the glued 
> (referenced, associated, linked, whatever) data is not 
> trivial. Should you write "The <ref href="Miami.xml">..." 
> (notice "The") or simply start with the <href>? If you're 
> describing many properties in one sentence, like in your 
> tides example, how do you present the properties, one by one, 
> or in a group reference ("The tides are <href>." or "The 
> tides are <href> and <href>") because that affects what 
> happens if you only want to reference one of the properties. 
> Et cetera.
> > 
> > And do you leave out the base property (the city name, in 
> your example) and reference to it (as in your example), or do 
> you include it but wrap it in an element ("<href>Miami</href>...")?
> > 
> > What happens if you need to translate the source to a 
> language with a radically different syntax in terms of 
> singular/plural forms, handling of prepositions, word separators, etc?
> > 
> > I've discussed some similar issues in a whitepaper for the 
> Extreme Markup conference that you may find helpful (or at 
> least readable; see 
> http://www.mulberrytech.com/Extreme/Proceedings/html/2003/Nord
> strom01/EML2003Nordstrom01.html).
> > 
> > Best,
> > 
> > /Ari
> >   _____
> > 
> > Ari Nordström - Consultant XML/SGML
> > Sörman Information & Media AB, Celsiusgatan 8, 702 74 
> Göteborg, SWEDEN
> > www.sorman.com
> > 
> > > -----Original Message-----
> > > From: Roger L. Costello [mailto:costello@mitre.org]
> > > Sent: 18 August 2003 18:35
> > > To: xml-dev@lists.xml.org
> > > Subject: A standard approach to glueing together reusable XML
> > > fragments
> > > in prose?
> > >
> > >
> > > Hi Folks,
> > >
> > > I am working with some people who wish to migrate from an
> > > all-prose format to a prose-plus-reusable-XML-fragments
> > > format.
> > >
> > > They have some data in prose that is useable in many 
> contexts.  They
> > > want to break out that reusable data  into XML fragments. 
>  However,
> > > they want to continue to provide the prose style.
> > >
> > > For example, consider this prose data:
> > >
> > > <para>The city of Miami, Florida (pop. 1, 234,000) is a 
> sprawling city
> > > with many attractions.  Miami Beach is a popular attraction.  The
> > > spring tide is ... The neap tide is ... </para>
> > >
> > > Examining this prose we can extract reusable info about 
> the city of
> > > Miami:
> > >
> > > <City id="Miami">
> > >     <state>Florida</state>
> > >     <population>1,234,000</population>
> > > </City>
> > >
> > > We can also extract reusable info about tide data on Miami Beach:
> > >
> > > <TideData id="MiamiBeachTides">
> > >     <springTide>...</springTide>
> > >     <neapTide>...</neapTide>
> > > </TideData>
> > >
> > > The problem now is to create a framework which allows the prose
> > > to bring-together the independent, reusable XML components.
> > > Conceptually, what is desired is a "glue framework" like this:
> > >
> > > <para>The <ref href="Miami.xml"> is a sprawling city with
> > > many attractions.  Miami Beach is a popular attraction.  The
> > > tides are <ref href="MiamiBeachTides.xml"><para>
> > >
> > > Thus, the prose is "glueing" together the XML fragments.
> > >
> > > Is this a problem that you have experience with?  What  "glue
> > > framework" have you used?  What strategy did you use to merge
> > > the XML fragments with the prose?  Is there is a standard way
> > > of combining semi-structured data with structured data?
> > > /Roger
> > >
> > >
> > >
> > 
> > -----------------------------------------------------------------
> > The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> > initiative of OASIS <http://www.oasis-open.org>
> > 
> > The list archives are at http://lists.xml.org/archives/xml-dev/
> > 
> > To subscribe or unsubscribe from this list use the subscription
> > manager: <http://lists.xml.org/ob/adm.pl>
> 




 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS