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:

Karol Krenski <[log in to unmask]>

Reply-To:

Karol Krenski <[log in to unmask]>

Date:

Sat, 29 Dec 2007 23:37:06 +0100

Content-Type:

text/plain

Parts/Attachments:

Parts/Attachments

text/plain (162 lines)

On Sat, Dec 29, 2007 at 08:38:13AM -0500, G. Ken Holman wrote:
> 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?
I mean the 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?
Most (all?) of the hardware/software throughout the whole Polish
National Fire Service deparments are PCs with various versions of
MSWindows. The individuals are not strictly required to use any special
platforms, nothing prevents them from using Linux in the future. 

> >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 don't mean anything specific here. Just in general, for modeling an
arbitrary abstract domains. Except from the strictly tabular data, like
describing scalar fields. 

 
> >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".
I'll try to be more specific then. Right now all the descriptions of what
happened during a fire-rescue operation is categorized and put into a
database, by filling the forms:

accident size:
[ ] small
[ ] medium
[ ] large

accident type:
[ ] forest fire
[ ] building fire
[ ] wehicle crash

...

start time: ________________
officer in charge: _____________________
amount of water used: _________________
how many injured: ______________

and like +20 questions of this sort.


Then the 'prose' as you call is filled:

At 12:30 our unit came to the car crash place at Amanda Street 13. There
was an oil splash on the street which probably caused the accident. One
car, Ford Focus lied on it's back, the other car, Mazda 323 was badly
crashed and its fuel was leaking. There were two people inside Mazda,
they weren't moving. The Officer in Charge, kpt. Norris ordered two
rescuers to put foam in order to cover leaked fuel and disable Mazda's
accumulator. The other rescuers opened the car with hydraulic equipment.
Next (...)

My research is to convert this prose into computer understandable form.
Most of the details about what actions were taken and what really
happened is available only by reading the prose. 

Just to make things clear: I am not trying to convert the old data into
XML. I am focused on how to fill the data in the future so that
computers like it.

> 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.
Yes, I appreciate your help very much, Ken. Thanks for all the advices
and issues to consider. The last hints about structured/unstructured
nature of the data touch the core of the problem. The data I am trying
to deal with, need reach vocabulary which directs the resulting data
into a prose and away from the structured data. Seems to me it can't be
definately judged that XML was a mistake and a database was the obvious
choice and this is a lot to me.

Thanks once more
Karol

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