XML

J

Thread Starter

jackh

Hi,

I have been working on a project that compliments the Puffin project, it uses a ladder logic interpreter instead of a compiler. For my project
(FreeLC) I am using XML to store and transfer data between different modules. Right now this is the logic engine, and the programming software. Eventually this will also be used to communicate with a Java based HMI. I know that some of the people in the Puffin project have stated an interest in XML, so I am looking for comments or criticisms. I have included a file that I am currently able to import/export from the PLC and the programming software.

Hugh
email: [email protected]
web: claymore.engineer.gvsu.edu/~jackh



--------------------------- XML file ----------------------------------

<?xml version="1.0" standalone="yes"?>
<!DOCTYPE plc SYSTEM "plc.dtd">

<plc>

<memory>
<integer type="output" location="0" size="10" comment="Output
Memory"></integer>
<integer type="input" location="1" size="10" comment="Input
Memory"></integer>
<timer location="4" size="4" comment="Timer Memory">
<set location="0" symbol="WAIT" comment="This is a test timer"
base="0.01" delay="40" accumulator="0"></set>
&lt;/timer>
&lt;integer type="integer" location="7" size="5" comment="Integer
Memory">
&lt;set location="0" value="123" symbol="TEST1"></set>
&lt;set location="2" value="456" symbol="TEST2"></set>
&lt;/integer>
&lt;string location="9" size="10">
&lt;set location="0" value="SEND #0 \"Test String\""></set>
&lt;set location="1" value="This is a test string to last
\"ferever\"">&lt;/set>
&lt;set location="2" value="APPEND MEMORY ST9:3 WORM #0"></set>
&lt;set location="3" value="APPEND #0 SEND MEMORY ST9:3">&lt;/set>
&lt;set location="4" value="abc">&lt;/set>
&lt;set location="5" value="def">&lt;/set>
&lt;set location="6" value="ghi">&lt;/set>
&lt;set location="7" value="jkl">&lt;/set>
&lt;set location="8" value="mno">&lt;/set>
&lt;set location="9" value="pqr">&lt;/set>
&lt;/string>
&lt;/memory>

&lt;io>
&lt;serial port="/dev/ttyS1" connection="program 0">&lt;/serial>
&lt;serial port="/dev/ttyS0" connection="worm 0">&lt;/serial>
&lt;network port="1234" connection="worm 1">&lt;/network>
&lt;network port="1235" connection="synchronous">&lt;/network>
&lt;card base="0x300" type="das08" comment="DAS08">
&lt;scan memory="N7:0" type="output" channel="AUX">&lt;/scan>
&lt;/card>
&lt;/io>

&lt;program>
&lt;ladder location="2" comment="This is the main program">
&lt;line instruction="SOR" comment="A Test Line">&lt;/line>
&lt;line instruction="XIO I1:000/0" comment="A Test Line">&lt;/line>
&lt;line instruction="BST">&lt;/line>
&lt;line instruction="OTE O0:000/0">&lt;/line>
&lt;line instruction="NXB">&lt;/line>
&lt;line instruction="MSG ST9:2 R6:0">&lt;/line>
&lt;line instruction="BND">&lt;/line>
&lt;line instruction="EOR">&lt;/line>
&lt;line instruction="SOR">&lt;/line>
&lt;line instruction="END">&lt;/line>
&lt;line instruction="EOR">&lt;/line>
&lt;/ladder>
&lt;/program>

&lt;/plc>

------------------------------------- END of File
------------------------------


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi Jack

After carefully assessing the risk of immolation and against my better judgement, my curiosity has overcome the fear of exposing my ignorance and lack of buzzword compliance. I will admit my prejudice against MS properties that have since become standards and ask:
In the context of what should be the tightly coded and optimized for efficiency innards of a PLC, what does XML bring to the table?
This is a technical question, an honest one, as I have not researched XML to any great extent, particularly in this context.. Those on the list who know should feel free to explain also. I'm sure there are others who would benefit also.

regards

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
On Sat, Sep 02, 2000 at 01:55:50PM -0500, Curt Wuollet wrote:

> After carefully assessing the risk of immolation and against my better
> judgement, my curiosity has overcome the fear of exposing my ignorance
> and lack of buzzword compliance. I will admit my prejudice against MS
> properties that have since become standards and ask:

...before addressing the question, I don't think it is particularly valid to associate XML with MS. MS did "embrace" XML, but their
implementations have not been particularly good models of standards compliance (possibly because they released very early), and are (or at least have been) the cause of a lot of annoying questions to XML lists with MS-specific answers.

> In the context of what should be the tightly coded and optimized for
> efficiency innards of a PLC, what does XML bring to the table?

The innards of anything not necessarily the place for XML.

One way to view XML that I've seen is something like "as ASCII is to character encodings, XML is to structured information". EBCDIC and other encodings are equivalent to ASCII in that they do the same thing, serve the same purpose. But by (more or less arbitrarily) standardizing on ASCII, information is much more easily understood, regardless of its source.

XML is pretty much equivalent to other means of storing information, e.g., comma-separated values, lines of tag=value entries, Windows INI
file format, packed binary formats, etc. The (or at least one) value of XML is simply that it allows getting past the question of what scheme
is to be used, e.g., for a configuration file.

In an isolated application, there may be little reason to use XML. If you're defining a config file format, and can parse it, maybe build an
editor for it, then fine, use whatever rings your bell. ;)

On the other hand, if XML is used, then there's a good chance that generic tools could be used to parse, edit, view, and otherwise process the stored data, and the application code just got a little smaller.

> This is a technical question, an honest one, as I have not researched XML
> to any great extent, particularly in this context.. Those on the list who
> know should feel free to explain also. I'm sure there are others who
> would benefit also.

Some other possible reasons to use XML: it is fully and carefully specified, well thought out, and many potential gotchas (e.g., of an ad hoc data format) can be avoided. It can be (or seem to be) very complex, but it doesn't need to be, and simple subsets of the full spec can be used. It is very flexible, and allows quite a bit of freedom in choosing the actual application language to use. It uses plain text, so can be read or processed by hand (though that's not necessarily how it is best used). XML parsers do not accept not-well-formed XML, so there's a level of purely structural validation imposed.

Some cons of XML: It is more verbose than many other formats. It is encumbered by hype and buzzworditus. Certainly, more cons could be
listed...

To the "bloated" argument, the standard response is that XML, as plain text, compresses very well, and using XML-aware compression, maybe even
better than arbitrary text. Again, the innards of an application wouldn't necessarily be using XML, so the bloat wouldn't be a problem there anyway. Some applications using XML for configuration or data file storage (e.g., Dia is one) use compression by default, so the actual stored file is not large.

Finally, I'd offer the thought that arguing XML-vs-some-other-format can easily degenerate into a religious argument. XML is not magic, it's just a flexible structured data format that has arbitrarily been proffered as a standard for wide use.

Ken

--
Ken Irving
Trident Software
[email protected]

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Ken Irving wrote:

> ...before addressing the question, I don't think it is particularly
> valid to associate XML with MS. MS did "embrace" XML, but their
> implementations have not been particularly good models of standards
> compliance (possibly because they released very early), and are (or at
> least have been) the cause of a lot of annoying questions to XML lists
> with MS-specific answers.

Are they not driving it and can we expect stabilization while they are extending it? Can we define a stable subset for our use and remain
"standards compliant". I'm all for standards, if open and immutable for competitive purposes. IBM weighing in on this one does add a little
credence to the open part. MS has no credibility on open anything.

> > In the context of what should be the tightly coded and optimized for
> > efficiency innards of a PLC, what does XML bring to the table?
>
> The innards of anything not necessarily the place for XML.
>
> One way to view XML that I've seen is something like "as ASCII is to
> character encodings, XML is to structured information". EBCDIC and
> other encodings are equivalent to ASCII in that they do the same thing,
> serve the same purpose. But by (more or less arbitrarily) standardizing
> on ASCII, information is much more easily understood, regardless of
> its source.
>
> XML is pretty much equivalent to other means of storing information,
> e.g., comma-separated values, lines of tag=value entries, Windows INI
> file format, packed binary formats, etc. The (or at least one) value
> of XML is simply that it allows getting past the question of what scheme
> is to be used, e.g., for a configuration file.

Who makes the rules? What would I have to read to do a conformant parmfile?

> In an isolated application, there may be little reason to use XML. If
> you're defining a config file format, and can parse it, maybe build an
> editor for it, then fine, use whatever rings your bell. ;)
>
> On the other hand, if XML is used, then there's a good chance that
> generic tools could be used to parse, edit, view, and otherwise process
> the stored data, and the application code just got a little smaller.

I wonder if this would be the case for our fairly specialized envronment.

> > This is a technical question, an honest one, as I have not researched XML
> > to any great extent, particularly in this context.. Those on the list who
> > know should feel free to explain also. I'm sure there are others who
> > would benefit also.
>
> Some other possible reasons to use XML: it is fully and carefully specified,
> well thought out, and many potential gotchas (e.g., of an ad hoc data format)
> can be avoided. It can be (or seem to be) very complex, but it doesn't need
> to be, and simple subsets of the full spec can be used. It is very flexible,
> and allows quite a bit of freedom in choosing the actual application language
> to use. It uses plain text, so can be read or processed by hand (though that's
> not necessarily how it is best used). XML parsers do not accept not-well-formed
> XML, so there's a level of purely structural validation imposed.

Is there a OSS parser that you've heard of? I've seen some buzz someplace on the Linux sites, but I can't recall where.

> Some cons of XML: It is more verbose than many other formats. It is
> encumbered by hype and buzzworditus. Certainly, more cons could be
> listed...
>
> To the "bloated" argument, the standard response is that XML, as plain
> text, compresses very well, and using XML-aware compression, maybe even
> better than arbitrary text. Again, the innards of an application wouldn't
> necessarily be using XML, so the bloat wouldn't be a problem there anyway.
> Some applications using XML for configuration or data file storage (e.g.,
> Dia is one) use compression by default, so the actual stored file is
> not large.
>
> Finally, I'd offer the thought that arguing XML-vs-some-other-format
> can easily degenerate into a religious argument. XML is not magic,
> it's just a flexible structured data format that has arbitrarily been
> proffered as a standard for wide use.

XML is fairly new, and the biggest buzz is about MS using it as the basis for SOAP or .NET or the MS vaporware of the day, I haven't paid that much attention. To use it seems ok, if learning it is going to be reusable knowlege. I'd be real leary of depending on it. In that isolated case, we do the structure, we have the source for the parser, we can use any arbitrary encoding language and get away with it. In the general case, I'm concerned about the old moving standards game
honed to excellence by some of those same vendors. It seems that their reason for standards is to get them into widespread use and then break everything on a regular basis to drive the upgrade mill. I don't think it unreasonable to want to avoid this when we depend on volunteer resources. That's why the relevent questions are what would we gain and who really controls it. Also will it be big in 5 years or go the way of so many buzzwords?

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
> Are they not driving it and can we expect stabilization while they are
> extending it? ...

I'd say they're not driving it at all. XML is completely defined by the W3C, which (I think) also defines HTML and other standards. The specs
(in the form of RFCs) are freely available. XML is really a simplified version (or instance?) of SGML, of which HTML is one example, and which has been around for a long time, long before MS became "aware" of it.

Microsoft has contributed a lot to the development, use, and application of XML; e.g., some MS employees have been very active. One very visible thing they did was to very quickly come out with an XML-aware browser, in IE5, but they managed to also screw some things up, in part since the RFCs hadn't really stabilized at the time. Mozilla (I guess) is or will be able
to render XML similarly. In both cases this is done using XSLT, a transformation language for XML (and in XML), to convert to HTML, since that's what the browsers understand. But this is "client" side XML; many would hold that the place to convert XML to HTMl is on the server, and there are many tools and systems that work this way.

IMHO, there is no basis for fearing Microsoft's influence in XML. SOAP, .NET, etc., are applications or protocols that use XML, but they "aren't" XML.

> ... Can we define a stable subset for our use and remain
> "standards compliant". ...

Yes, by all means! XML isn't really very complicated, despite the size of the RFCs. There are groups working on specifying strict subsets of XML, minimal-XML, common-XML, simple-XML (not the correct names), if it is important to have such sub-standards ;), but in part they're just
codifying some conventions to follow, whether to try to make parsing easier, parsers smaller, or whatever.


> ... I'm all for standards, if open and immutable for
> competitive purposes. ...

XML is just that.

> Who makes the rules? What would I have to read to do a conformant parmfile?

You can (and probably should) read the relevant RFCs available on the W3C site, if that turns your crank, but there are also more concise descriptions, tutorials, etc. around. The W3C (which is some sort of voting consortia?) has defined XML, but it's not likely to change much from this point.

I could offer a list of XML rules:

* the first line has to identify the XML version (to be formally correct)

* there must be one primary element

* each element consists of a starting tag, content, and a closing tag

* elements cannot overlap

* certain content text must be "escaped", e.g,. '>' must be '&gt;'

* elements can have attributes

* attributes must be unique

* attribute values must be in quotes (double or single)

Some short (if useless) XML documents:

&lt;?xml version="1.0"?>
&lt;a/>

&lt;?xml version="1.0"?>
&lt;a>
&lt;b x="an attribute"/>
&lt;b>this is the second "b" element's content&lt;/b>
&lt;d>&lt;e/>some XML languages eschew mixed content&lt;/d>
&lt;f x="whatever">content&lt;/f>
&lt;/a>

An example of a not-XML document due to overlapping elements:

&lt;?xml version="1.0"?>
&lt;a> &lt;b> &lt;c> &lt;/c> &lt;/b> &lt;/a>

> >
> > On the other hand, if XML is used, then there's a good chance that
> > generic tools could be used to parse, edit, view, and otherwise process
> > the stored data, and the application code just got a little smaller.
>
> I wonder if this would be the case for our fairly specialized envronment.

I don't see why it wouldn't be, but I suppose it depends on what the XML is used for. Many of available XML tools (e.g., Perl's) use the Expat parser, which is written in C. The Gnome project includes the libxml library, which has a parser and other tools.

> Is there a OSS parser that you've heard of? I've seen some buzz someplace on
> the Linux sites, but I can't recall where.

Expat is probably the standard one, very widely used. I've only used the Perl XML tools, which typically wrap Expat. The Gnome project has a libxml library, which includes a parser among other things.

>
> XML is fairly new, and the biggest buzz is about MS using it as the basis for
> SOAP or .NET or the MS vaporware of the day, I haven't paid that much attention.
> To use it seems ok, if learning it is going to be reusable knowlege. I'd be real
> leary of depending on it. In that isolated case, we do the structure, we have the
> source for the parser, we can use any arbitrary encoding language and get away
> with it. In the general case, I'm concerned about the old moving standards game
> honed to excellence by some of those same vendors. It seems that their reason
> for standards is to get them into widespread use and then break everything on
> a regular basis to drive the upgrade mill. I don't think it unreasonable to want to
> avoid this when we depend on volunteer resources.

IMHO the MS paranoia is misplaced in this case (but not in others ;), and I don't think there'll be big changes happening to XML, at least the basics.

> ... That's why the relevent
> questions are what would we gain and who really controls it. Also will it be big
> in 5 years or go the way of so many buzzwords?

What is gained is simply not having to invent yet another format for storing stuff. Sure, it's easy enough to do that, but why not just use what's available and standardized? In 5 years, I'd expect XML to be pretty boring, and in the same boat as such buzzwords as "ASCII", "file", "sockets", ...

--
Ken Irving
Trident Software
[email protected]

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
On Mon, Sep 04, 2000 at 06:08:29PM -0800, Ken Irving screwed up and wrote:
>
> An example of a not-XML document due to overlapping elements:
>
> &lt;?xml version="1.0"?>
> &lt;a> &lt;b> &lt;c> &lt;/c> &lt;/b> &lt;/a>
>

... which is well-formed. This isn't:

&lt;?xml version="1.0"?>
&lt;a> &lt;b> &lt;c> &lt;/b> &lt;/c> &lt;/a>

--
Ken Irving
Trident Software
[email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
I have been working with XML for over two years and I am a great supporter of XML, but stop !!!! The following is what I see as pro's and cons of using XML for a PLC project :

Benefits :
1. Easy access to Parsers (XML needs parser engine) which are mainly free.
2. Standard com platform. We can define our own tags and add or modify as we please, this can happen even at local level and it will not disturb the original code (They are just tags to parser).
3. It is the future of Web. Everyone in US is supporting parsers which can handle XML.
4. Extensible to industry specific requirement.

Drawbacks:
1. It is extremley inefficient and parsers do not support interrupts or anything to do with real time which we will need in a PLC project.
2. A large XML document will require a lot of processing. A PC104 based system will certainly fail. I use a dual 650 machine and it takes
almost 2 seconds for a document to get parsed (I am using the IBM parser at present).
3. Whole document has to be read before the Parser will release it.
4. Because parsers are not ours, what is the prospect of making it embedded ?

I hope this shines a little light on this path.
Thanks
Bob-

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hmmmm..............

We would need to write a micro parser with a feature set specific to our uses.........after learning XML...I don't know guys.... Hey Hugh, can you lend some insight on where the win is? Did you have external communications in mind or
consistancy with other software systems or distributed use, or?

regards

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
On Mon, Sep 04, 2000 at 10:36:36PM -0400, Bob wrote:
>
> Drawbacks:
> 1. It is extremley inefficient and parsers do not support interrupts
> or anything to do with real time which we will need in a PLC project.

Extremely inefficient compared to what? IIUC, XML would most likely be used (if at all ;) for a config file which is read at startup, and not in
the internal running of the machine.


> 2. A large XML document will require a lot of processing. A PC104
> based system will certainly fail. I use a dual 650 machine and it takes
> almost 2 seconds for a document to get parsed (I am using the IBM
> parser at present).

With an event-driven parser, I'd guess that the amount of processing would be proportional to the document size, so I guess I'd agree. I can't argue your assertion (regarding PC104), not having done it. Are you sure of that?


> 3. Whole document has to be read before the Parser will release it.

I don't think that's true for event-based parsers such as expat. Maybe that's the case for DOM (document object model) or validating parsers?
If so, then don't do that.

The expat-based parser I've used (Perl's XML::parser module) fires off events (e.g,. start-of-element) as the file is being read. In a non-well-formed document I see events up to where the error is found.


> 4. Because parsers are not ours, what is the prospect of making it
> embedded ?

The expat parser can be used under the GPL; wouldn't that cover it?

--
Ken Irving
Trident Software
[email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Ken Irving:
> One way to view XML that I've seen is something like "as ASCII is to
> character encodings, XML is to structured information".

The more I read about XML, the more it seems to me it's a bit like TIFF is to images.

(For those of you not familiar with TIFF - the first two bytes are
either II or MM, and this determines the endianness of the rest of
the file. This philosophy is applied throughout the format, leading
to a huge open-ended array of options and variants.)


While it may avoid the pitfalls of designing a file format from ASCII, it seems to me it would create many pitfalls of its own. Should various values be attributes or contents? Should this be a tag name or an attribute of a generic tag? In which way should this (generic graph) data be factored into a hierarchy?

No doubt with experience these pitfalls can be avoided, just as experience can avoid the pitfalls of ASCII files.

Yet if we will choose a sophisticated format for our files, we should ensure that it will fit the intended application well. Does our data
correspond well to the model of XML? I'm not sure - I'm not very familiar with XML, and we do not know our data well yet. Still, already there is one piece of data that may end up a Petri net - basically a generic directed graph. Other pieces of data may be two-dimensional grids. These may not map well.

If we choose our file format poorly, we will end up distorting our data to fit. I favour using the simplest possible format, so that our distortions
may be simpler, at least until we see the shape of our data. Then, and only then, may we choose or tailor a file format for them.

(Just as an exercise: list the pros and cons of XML compared to n-th Normal Form, for n of your choice.)


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

> The more I read about XML, the more it seems to me it's a bit like TIFF is
> to images.
>
> (For those of you not familiar with TIFF - the first two bytes are
> either II or MM, and this determines the endianness of the rest of
> the file. This philosophy is applied throughout the format, leading
> to a huge open-ended array of options and variants.)

Do you refer to character encodings? Although this is defined in the XML spec, it refers to the byte representation of your XML files.

> Does our data
> correspond well to the model of XML? I'm not sure - I'm not very familiar
> with XML, and we do not know our data well yet.

XML has no data model. As its name indicates, it is a markup language. Basically, you "highlight" parts of your document with a tag and the tag name hopefully has some semantic meaning to you.

> Still, already there is one
> piece of data that may end up a Petri net - basically a generic directed
> graph. Other pieces of data may be two-dimensional grids. These may not map
> well.

Exactly to the point! First, develop your application or domain-specific model. This can be done, for instance, using entity relationship diagrams, the Unified Modelling Language, etc. Then specify the mapping to a textual representation using XML. As long as the (data?) model of the PuffinPLC is not clear, XML does not
help but is simply a pain (i.t.a).

You probably will have a set of XML documents, with specifications for different areas, like for the process image, ladder diagrams (shudder...), maybe even an XML sidekick for structured text of
1131 fame...

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238
email: [email protected]-aachen.de

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
D

David Nimmons

I don't know much about XML myself, but I believe XML would be good for storing data to a file and also as a way of communicating data to a HMI.

As far as it being a Microsoft controlled standard, tain't so. They have attempted to embrace and extend the standard of course, but, have failed so far. It appears that the next HTML spec from the w3c will combine HTML and XML.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > The more I read about XML, the more it seems to me it's a bit like TIFF
> > is to images.

> > (For those of you not familiar with TIFF - the first two bytes are
> > either II or MM, and this determines the endianness of the rest of
> > the file. This philosophy is applied throughout the format, leading
> > to a huge open-ended array of options and variants.)

Harald Albrecht:
> Do you refer to character encodings? Although this is defined in the XML
> spec, it refers to the byte representation of your XML files.

No, I refer to a myriad of options and possibilities, so that any given data file can be represented in almost endless ways. Maybe I'm wrong, that's just the impression I get at a distance.

> > Does our data correspond well to the model of XML? I'm not sure - I'm
> > not very familiar with XML, and we do not know our data well yet.

> XML has no data model.

Yes it does - you may prefer to call it a meta-model, but it's there.

> As its name indicates, it is a markup language. Basically, you
> "highlight" parts of your document with a tag and the tag name hopefully
> has some semantic meaning to you.

There we are, that's XML's data model, the one-sentence description.

Even out here I know that XML's data model is a strict hierarchy. I believe it's one of its most-commonly-cited restrictions. Does it matter for us? I don't know. But that's just the first level - no doubt there are other more subtle issues, no less restrictive for their subtlety.

> > Still, already there is one piece of data that may end up a Petri net -
> > basically a generic directed graph. Other pieces of data may be
> > two-dimensional grids. These may not map well.

> Exactly to the point! First, develop your application or domain- specific
> model. This can be done, for instance, using entity relationship
> diagrams, the Unified Modelling Language, etc. Then specify the mapping
> to a textual representation using XML.

Actually, at this point is the right time to ask whether the data is best represented using XML, relational database, flat database, a text file or
some other technique. They each have their advantages and disadvantages; SQL databases can be modified on-line, for instance, whereas XML files must be closed, replaced and re-parsed.

"At the end of the road can you decide whether to turn to the right or to the left. If you set out on the road, already decided, you will reach
nothing except a bad end." (Or words to that effect.)

> As long as the (data?) model of the PuffinPLC is not clear, XML does not
> help but is simply a pain (i.t.a).

Yes, that's true for any data format design.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
M

Mario de Sousa

Jiri Baum wrote:

> Jiri Baum:
> (...)
> > > Does our data correspond well to the model of XML? I'm not sure - I'm
> > > not very familiar with XML, and we do not know our data well yet.
>
> > XML has no data model.
>
> Yes it does - you may prefer to call it a meta-model, but it's there.

>
> > As its name indicates, it is a markup language. Basically, you
> > "highlight" parts of your document with a tag and the tag name hopefully
> > has some semantic meaning to you.
>
> There we are, that's XML's data model, the one-sentence description.
>
> Even out here I know that XML's data model is a strict hierarchy. I believe
> it's one of its most-commonly-cited restrictions. Does it matter for us? I
> don't know. But that's just the first level - no doubt there are other more
> subtle issues, no less restrictive for their subtlety.
>

I'm sorry for butting in on something I know very little about, so please correct me if I am wrong. Al I know about XML is the buzzword and what has
been said on the list.

I seem to get the impression that, apart from special syntax, XML is a hierarquical organization of (name, value) pairs. If this is true, it seems to me that our current config file structure is easily mapped onto XML. The config file structure contains name=value pairs (ex. sem_key=42) and matrix indexed by row (i.e. line) and column (e.x. point P0 ..... ; point P1
...., etc). These values are grouped into sections (ex. [SMM]).
Am I wrong in supposing that this could be mapped onto XML using something like
section=SMM {
name=sem_key {
value=42
}
table=point {
line=1 {
column=1 {
value=P0}
}
}
} /* end SMM */
section=PID {
...
}

This means that as long as we keep to the current strcuture, we will always be able to map it onto XML. I'm sure we can map it into a relational database (SQL), but I haven't given any thought on that. It would be nice if this were true because that meant we could just keep going as we have until now, and later, when more people are willing to contribute code, or when other more
fundamental aspects have been dealt with, these mappings can be coded. Please don't take me wrong, I too think it is important to think about this now, before we go heading into a dead end.


----------------------------------------------------------------------------
Mario J. R. de Sousa [email protected]
----------------------------------------------------------------------------


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

Jiri:
>Harald:
>> XML has no data model.
>Yes it does - you may prefer to call it a meta-model, but it's there.

Correct. For all those out there how now thing that we've gone meta -- that is, crazy -- let's explain this:

0. bottom level: so-called instance level, that is the level where all the objects "float" around. Basically chunks of memory to hold
attributes and references to methods. For XML, this would be your file.xml with whatever data you want.

1. next level: class or model level. This defines the data model used in your file.xml. Various description methodologies are available, like DTD's and schemas. DTD's (Document Template
Definitions) are restricted in that they can only describe what tags are valid, how the tags can be nested and what kind of data can be within tags (parsed character data, no data at all, etc). Schemas are much more flexible but their spec is still in float. Schemas can in addition describe the type of data expected between the opening and closing tag up to the point of valid values.

2. another level: meta level. This defines the basic blocks with which level 1 (class/model level) can be defined. It's sort of LEGO bricks. As for XML, the XML spec eventually defines this level: that there are tags (delemited by "<" and ">"), that tags can have attributes, etc. Jiri prefers to call this "XML's data model".

> Actually, at this point is the right time to ask whether the data is
> best represented using XML, relational database, flat database, a
> text file or some other technique. They each have their
> advantages and disadvantages; SQL databases can be modified
> on-line, for instance, whereas XML files must be closed, replaced
> and re-parsed.

If you "just" write an appropriate abstraction object, the fact that an XML file is parsed, its contents are changed and later written back
is totally invisible to the user. This is the same as with a database (whether SQL or not). Even for flat text files, like Microsoft's .INI
files there is such an abstraction -- you don't parse the .ini file but instead retrieve or set values and Win32 takes care of this.

Harald

--
Harald Albrecht
Chair of Process Control Engineering
RWTH Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238
email: [email protected]-aachen.de

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > XML's data model is a strict hierarchy. I believe it's one of its
> > most-commonly-cited restrictions. Does it matter for us? I don't know.
> > But that's just the first level - no doubt there are other more subtle
> > issues, no less restrictive for their subtlety.

Mario de Sousa wrote:
> I seem to get the impression that, apart from special syntax, XML is a
> hierarquical organization of (name, value) pairs.

Not really - it's a sort of generalization of HTML. Basically you have text, and you can mark parts of that text with tags; each of those tags can have attributes. Tags can be nested, but only strictly hierarchically.

I'm not particularly familiar with XML; one of my worries is whether (and how well) the properties of this approach have been studied, to guide the
hand of the format designer. How extensive and accepted is the literature on this point? Are there books, courses, magazine tutorials on designing effective XML formats?

In the absence of a solid foundation much design will inevitably end up baroque, inflexible and ultimately unsatisfactory.

> If this is true, it seems to me that our current config file structure is
> easily mapped onto XML. The config file structure contains name=value
> pairs (ex. sem_key=42) and matrix indexed by row (i.e. line) and column
> (e.x. point P0 ..... ; point P1 ...., etc). These values are grouped into
> sections (ex. [SMM]).
> Am I wrong in supposing that this could be mapped onto XML using something
> like
> section=SMM {
> name=sem_key {
> value=42
> }
> table=point {
> line=1 {
> column=1 {
> value=P0}
> }
> }
> } /* end SMM */
> section=PID {
> ...
> }

That's one way of mapping it, but it's by no means the only way, or necessarily the best. The explicit line and column numbers, for instance,
are probably the wrong thing (though explicit column *names* may be a very good idea indeed).

(Indeed, my design of the linuxplc.conf file is wide open for criticism. I just designed it intuitively, "willy-nilly" as they say, so it wouldn't be surprising if it had something of the baroque, the inflexible and the ultimately unsatisfactory that I levied against poor design.)

> This means that as long as we keep to the current strcuture, we will
> always be able to map it onto XML. I'm sure we can map it into a
> relational database (SQL), but I haven't given any thought on that. It
> would be nice if this were true because that meant we could just keep
> going as we have until now, and later, when more people are willing to
> contribute code, or when other more fundamental aspects have been dealt
> with, these mappings can be coded.

Personally, I'd stick with what we are doing unless somebody can come up with a compelling case for XML/SQL/whatever (or writes the code - that's fine with me too).

Actually, I might even rephrase it the other way: I'd stick with what we are doing unless somebody writes the code for XML/SQL/whatever (or can come
up with a compelling case - that's fine with me too).


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Harald:
> >> XML has no data model.
Jiri:
> >Yes it does - you may prefer to call it a meta-model, but it's there.

Harald Albrecht:
> Correct. For all those out there how now thing that we've gone meta --
> that is, crazy -- let's explain this:

> 0. bottom level: so-called instance level,
...
> 1. next level: class or model level.
...
> 2. another level: meta level. [...] Jiri prefers to call this "XML's data
> model".

Actually, that's not what I said; not that it matters (I asked whether our data corresponds to the model of XML - which is consistent with your usage, if perhaps not very clear).

In any case, XML has a certain model of what data looks like, regardless of the actual tags defined. All data is hierarchical, for instance. There's nothing you can do about it, it is intrinsic to XML, a part of the data model which defined by level 2.

Much of the data model is in the class definition, but certain parts of it, too fundamental or too trivial for the class level, are in XML itself. I do not know whether one could avoid that, nor how - but XML certainly doesn't.

We don't (much) care for the trivial, of course, but the fundamental may yet trip us up.

Xanadu, I believe, is fundamentally incompatible with XML for this reason.

...
> > SQL databases can be modified on-line, for instance, whereas XML files
> > must be closed, replaced and re-parsed.

> If you "just" write an appropriate abstraction object, the fact that an
> XML file is parsed, its contents are changed and later written back is
> totally invisible to the user.

I meant the other way - when some other program wishes to change the data. Relational databases have well-defined, time-proven semantics for multiple access (with well-known problems).

I'm not aware of any such protocol for XML.

> This is the same as with a database (whether SQL or not).

Except that an SQL database is designed with multiple users in mind, all modifying the database concurrently. I'm don't think XML provides that, and for a Microsoft product it would be a miracle of Biblical proportions.


Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
K
...
> I meant the other way - when some other program wishes to change the data.
> Relational databases have well-defined, time-proven semantics for multiple
> access (with well-known problems).
>
> I'm not aware of any such protocol for XML.

That's not the domain of XML, which is simply a file (or stream) format.

--
Ken Irving
Trident Software
[email protected]


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Jiri Baum:
> > I meant the other way - when some other program wishes to change the
> > data. Relational databases have well-defined, time-proven semantics
> > for multiple access (with well-known problems).

> > I'm not aware of any such protocol for XML.

Ken Irving:
> That's not the domain of XML, which is simply a file (or stream) format.

Exactly.

Is such a protocol available for XML? (It doesn't have to be implemented; at this stage I just want to know whether it exists.)

Of course, at this point we may agree that we don't need such a protocol, in which case the point is irrelevant. Still it is worthwhile to ask, this and many other questions, for some of them may well be relevant and even decisive.

Jiri
--
Jiri Baum <[email protected]>
What we do Every Night! Take Over the World! Step 1 - bid for SMOFcon

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
> Is such a protocol available for XML? (It doesn't have to be implemented;
> at this stage I just want to know whether it exists.)

WebDAV. http://www.webdav.org/ is a good starting point. It definitely exists -- mod_dav for Apache is at 1.0, and IIRC will be incorporated into Apache 2.0. I *think* that Microsoft's "Web Folders" are supposed to be WebDAV-enabled, but I haven't verified that yet.

FYI,

Zach Frey

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top