LISTSERV mailing list manager LISTSERV 16.0

Help for XML-L Archives


XML-L Archives

XML-L Archives


XML-L@LISTSERV.HEANET.IE


View:

Message:

[

First

|

Previous

|

Next

|

Last

]

By Topic:

[

First

|

Previous

|

Next

|

Last

]

By Author:

[

First

|

Previous

|

Next

|

Last

]

Font:

Proportional Font

LISTSERV Archives

LISTSERV Archives

XML-L Home

XML-L Home

XML-L  December 2007

XML-L December 2007

Subject:

Re: describing fire-rescue actions in xml

From:

"G. Ken Holman" <[log in to unmask]>

Reply-To:

General discussion of Extensible Markup Language <[log in to unmask]>

Date:

Sat, 29 Dec 2007 08:38:13 -0500

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (112 lines)

At 2007-12-29 11:29 +0100, Karol Krenski wrote:
>I am doing a scientific research for my Phd thesis. The idea is to
>describe fire-rescue operations in a computer-friendly form. My first
>idea was to create a new language and XML came immediately to my mind as
>the language allowing for description of any domain. Last few months I
>was learning about XML, RelaxNG and XSLT technologies. The more I am
>into it, the more doubt arises about choosing the right tools for the
>task.

When you say "tools", are you asking about the appropriateness of the 
technology, or the vendor tools to work with that technology?

>The XML power may come from its ability to exchange documents among
>different organizations, which haven't stuck to a common standard. But
>the National Fire Service will not exchange their documents with outside
>world and can easily agree on one standard - the standard may be
>specified by some headquarters department.

Fine ... so you have a closed environment.  Are all of the 
hardware/software platforms identical in this closed community, or 
can individuals select their own systems?

>The National Fire Service works in computer network environment. Then
>the alternative is to use a relational database and create the language
>using database schemas. This would additionaly allow for faster queries
>if the data would feed the decission support system (which is not my
>main focus). But the big question is 'do database schemas are as much
>descriptive as XML'?

A bigger question might be "descriptive of what?".

>I know nothing about databases and certainly don't
>have the big picture of existing technologies and their applications.

Then it might be difficult to compare.

>I would much prefer to use XML - I am already familiar with it and
>researched XML's applications: SVG and MathMl. What I am really looking
>for is the arguments in XML vs relational databases in favour of the
>first one. Could I please ask you for a comment?

The only description of your information that you have provided is 
"describe fire-rescue operations in a computer-friendly form".

This is very different than describing, say, the lists of ignition 
temperatures for different building materials, or the street numbers 
of residences for a given street.  Not being familiar with your 
world, I'm just trying to guess the kind of information that would be 
looked up in a database, where you have a key value and associated 
lookup values with that key.  Your needs for accessing the 
information lead you to choose the appropriate technology.  A 
relational database seems quite suitable for such lookup/return 
accessibility to such information.

If describing fire-rescue operations are done in one or more human 
languages, then you aren't dealing with atomic values being returned 
from the query of a single key value.  You are instead dealing with 
prose.  And interspersed within that prose is information that has 
meaning (participants, participant roles, equipment, statute 
references, etc.).  Again, ask yourself how are you going to be 
accessing the information, and this will help you choose the 
technology.  Your goals may be to rearrange the information into 
different human languages (for pan-European standardization, or 
Canadian English/French bilingual reasons), with different 
presentations on the web (using XSLT/XHTML) or on paper (using 
XSLT/XSL-FO), or for different audiences (summary procedures for 
management, detailed procedures for safety personnel).

Only you can know how you envisage maintaining this information:

  - where will you find it?
  - how will it be entered into the system?
  - how will it be retrieved from the system?
  - how will it be rearranged into arrangements for different audiences?
  - how will it be presented to each audience?
  - what information needs to be gleaned from each arrangement?
  - (many more...)

Using XML is not a panacea.  It doesn't solve all problems well.  It 
does solve semi-structured and prose information very well.  It 
doesn't solve highly-structured high-speed-lookup tabular structure 
as well as database technology does.

In your experience with SVG and MathML, what is it about your use of 
these vocabularies that XML makes easy?  I suspect these 
semi-structured vocabularies give the power to the user to arrange 
the bits any way they wish in an unstructured fashion, but the bits 
themselves are structured.  Vocabularies like DocBook and DITA are 
structured collections of unstructured bits, where the section 
arrangements are structured but the paragraph contents inside those 
sections are unstructured.

Ask yourself:  are fire-rescue operations an unstructured collection 
of structured bits, or a structured collection of unstructured 
bits?  If not, then perhaps you don't need XML.

If you have a structured collection of structured bits, database 
technology might be more appropriate.

I hope this is helpful.

. . . . . . . . . . . . . . Ken

--
Comprehensive in-depth XSLT2/XSL-FO1.1 classes: Austin TX,Jan-2008
World-wide corporate, govt. & user group XML, XSL and UBL training
RSS feeds:     publicly-available developer resources and training
G. Ken Holman                 mailto:[log in to unmask]
Crane Softwrights Ltd.          http://www.CraneSoftwrights.com/l/
Box 266, Kars, Ontario CANADA K0A-2E0    +1(613)489-0999 (F:-0995)
Male Cancer Awareness Nov'07  http://www.CraneSoftwrights.com/l/bc
Legal business disclaimers:  http://www.CraneSoftwrights.com/legal

Top of Message | Previous Page | Permalink

Advanced Options


Options

Log In

Log In

Get Password

Get Password


Search Archives

Search Archives


Subscribe or Unsubscribe

Subscribe or Unsubscribe


Archives

February 2017
August 2016
June 2016
March 2016
January 2016
July 2014
April 2014
January 2014
July 2013
February 2013
September 2012
August 2012
October 2011
August 2011
June 2011
January 2011
November 2010
October 2010
July 2010
June 2010
March 2010
February 2010
January 2010
November 2009
September 2009
August 2009
July 2009
May 2009
March 2009
December 2008
October 2008
August 2008
May 2008
March 2008
February 2008
January 2008
December 2007
October 2007
August 2007
June 2007
March 2007
January 2007
December 2006
September 2006
July 2006
June 2006
April 2006
February 2006
January 2006
November 2005
September 2005
August 2005
July 2005
June 2005
May 2005
March 2005
January 2005
October 2004
August 2004
July 2004
June 2004
May 2004
March 2004
February 2004
January 2004
December 2003
November 2003
October 2003
September 2003
August 2003
July 2003
June 2003
May 2003
April 2003
March 2003
February 2003
January 2003
December 2002
November 2002
October 2002
September 2002
August 2002
July 2002
June 2002
May 2002
April 2002
March 2002
February 2002
January 2002
December 2001
November 2001
October 2001
September 2001
August 2001
July 2001
June 2001
May 2001
April 2001
March 2001
February 2001
January 2001
December 2000
November 2000
October 2000
September 2000
August 2000
July 2000
June 2000
May 2000
April 2000
March 2000
February 2000
January 2000
December 1999
November 1999
October 1999
September 1999
August 1999
July 1999
June 1999
May 1999
April 1999
March 1999
February 1999
January 1999
December 1998
November 1998
October 1998
September 1998
August 1998
July 1998
June 1998
May 1998
April 1998
March 1998
February 1998
December 1997
November 1997
October 1997

ATOM RSS1 RSS2



LISTSERV.HEANET.IE

Secured by F-Secure Anti-Virus CataList Email List Search Powered by the LISTSERV Email List Manager