XML Question - was I was wrong ...

J

Thread Starter

Jansen, Joe

So forgive me my ignorance, but I have not been able to find a good definition of XML. As best as I can find, It is a lot like HTML, only it allows user defined tags, and obviously is not tied to only doing document layout. Is this accurate?

If so, doesn't it seem to be an extremely verbose method of transferring data? Wouldn't that lead to inefficiencies in data transfer? I really do not know what the advantage of XML is in our
environment, based on my (probably incorrect) understanding. Can someone please give methe 'straight line' on XML in the IA area?

Thanks,

--Joe Jansen

->
-> XML offers the scope of a universal language that decribes the -> parameters of PLC's, drives, positioners, and everthing else we have -> to deal with, and gives the possibility of an interface that could be -> both machine readable and directly human readable without special -> drivers or code. -> -> BUT, I have some serious
reservations: -> -> Firstly, I do not understand how asynchronous event signaling -> would work under XML. OK, I am pretty ignorant on XML having -> never used it, but I have been discussing it with someone local who -> is developing XML based solutions for commerce applications. Can -> anybody enlighten me on what current proposals are? I would hate -> to think we must continuously poll all field units. ...<clip>
 
K
> From: "Jansen, Joe" <[email protected]>
>
> So forgive me my ignorance, but I have not been able to find a good
> definition of XML. As best as I can find, It is a lot like HTML, only
> it allows user defined tags, and obviously is not tied to only doing
> document layout. Is this accurate?

HTML has a specific (implicit at least) purpose, and a specific set of elements that mean certain things in the context of its intended users
(e.g., web browsers).

XML is a standard for formatting information, and defines no specific elements at all. It does define a very formal structure, and documents
that aren't "well-formed" according to the specification will not be processed by conforming XML agents.

Simple HTML can almost trivially be converted to XML conforming XHTML by making sure every open-tag has a matching closing-tag, ensuring that
elements are properly nested and not overlapping, and a few other simple measures. So, yes, XML is very similar to HTML, only more so. ;)

XML isn't concerned with how the information is used, transported, stored, viewed, etc., and anyone can invent an XML language for a desired purpose. Such a language will define specific elements, presumably with some particular meaning implied by each. However, any XML document will be XML, regardless of the intended use; it can be parsed, viewed as plain text, queried, etc., purely mechanically, without any knowledge of the
specifics of the particular language or its intended use. That, to me, is the advantage of, and power in, this technology.


> If so, doesn't it seem to be an extremely verbose method of
> transferring data? Wouldn't that lead to inefficiencies in data

Yes, it is verbose, and far more verbose than plenty of other schemes for moving data. In its defense, it is usually pointed out that, on the other hand, the simple, regular structure of XML
can allow for very effective compression, and this could be used to make its use more efficient. But IMHO that is beside the point.

For example, in simple textual configuration files, why would one choose XML over, say, a Windows INI file format, with lines of tag=value? In a specific, narrowly focused view, that's certainly a reasonable question, and an application might do well to not bother with XML at all. On the other hand, XML might allow a user of the application to view and edit the config file, and even to automate its processing, using tools that know nothing about the specifics of the application. IOW, such (XML) data can be handled by generic tools and components. There are low level XML manipulation libraries being bundled with OSes and application toolkits which will make this (using XML) even easier.

> transfer? I really do not know what the advantage of XML is in our
> environment, based on my (probably incorrect) understanding. Can
> someone please give methe 'straight line' on XML in the IA area?

I don't know about that, but I'd offer an analogy with storage formats used by word processors. Traditionally, each WP application can invent its own storage format, and can even take steps to keep the data hidden from view, and protected from tampering. On the one hand, this can be
seen as a way to protect the integrity of the data (the user's work), so that it is rendered correctly, etc.. But one might alternatively
hold that the data is being held hostage, and can only be released (used) by the original company's word processing software. It is in the interest of the WP company to do this, to make sure that its users keep using their products.

Now, if the WP data is instead stored using XML (even if compressed, as is common), then the user's work is not held hostage, and can be viewed
and manipulated by other software and systems. It might be converted for transport, viewing, condensing, summarizing, etc., but without any effort to specifically enable these things in the originating application. (This assumes that the particular XML dialect is not overly obfuscated, of course, to be too difficult to make sense of.) The WP companies can continue to compete, but will have to do so in the area of quality of
their applications instead of strong-arming their users.

In IA, as in other industries, XML is likely not the end-all and do-all technology that'll fix everything. It is a new(ish) and hot topic,
so there's lots of hype and expectations, exaggerations, etc., with claims and announcements appearing daily/hourly. However, as a simple, well defined format, I think it does have real value, particularly in the area of making information more easily available for disparate uses, but also in allowing the use of generic tools to work with it.

Ken

P.S. Re: finding a good description of XML, the W3C organization has the specs, but there are surely some concise descriptions of XML and
its potential uses and advantages floating around on the web. A search (google, yahoo, etc.) ought to yield quite a bit, if not way too much
information.

A google.com search for "good description of XML" yielded a page with the following:

XML in 6 points (URL: http://www.w3.org/XML/1999/XML-in-10-points )
by Bert Bos (W3C, 1999) A good description of XML for beginners.

(Hmm, I thought they said _6_ points... ) FWIW, those points are:

1. XML is a method for putting structured data in a text file
2. XML looks a bit like HTML but isn't HTML
3. XML is text, but isn't meant to be read
4. XML is a family of technologies
5. XML is verbose, but that is not a problem
6. XML is new, but not that new
7, 8, 9... These I don't know yet.
10. XML is license-free, platform-independent and well-supported


> -> XML offers the scope of a universal language that decribes the ->
> parameters of PLC's, drives, positioners, and everthing else we have
> -> to deal with, and gives the possibility of an interface that could
> be -> both machine readable and directly human readable without
> special -> drivers or code. -> -> BUT, I have some serious
> reservations: -> -> Firstly, I do not understand how asynchronous
> event signaling -> would work under XML. OK, I am pretty ignorant
> on
> XML having -> never used it, but I have been discussing it with
> someone local who -> is developing XML based solutions for
> comerce
> applications. Can -> anybody enlighten me on what current
> proposals
> are? I would hate -> to think we must continuously poll all field
> units. ...<clip>

--
Ken Irving
Trident Software
[email protected]
 
R
> So forgive me my ignorance, but I have not been able to find a good
> definition of XML. As best as I can find, It is a lot like HTML, only
> it allows user defined tags, and obviously is not tied to only doing
> document layout. Is this accurate?
>
> If so, doesn't it seem to be an extremely verbose method of
> transferring data?

Yes. So groups get together and produce 'distionaries' and 'schemas' which define a standard set of tags. I suppose, for example, a PLC could have standard tags

<run> and
<stop>

I suppose we could also e.g. define IEC symbols in terms of XML tags.

> Can
> someone please give methe 'straight line' on XML in the IA area?

Investigation of the www.xml.org site reveals that there is a group allready working on it. OPC are also working on COM objects being transported
by XML.

I feel XML dictionaries and schemas for IA and SCADA should reflect our environments and not be orienated around COM objects.
 
W

Walters Curt L Contr AEDC/SVT

My understanding of XML is that it is another markup language like HTML and SMGL, but it organizes the data hierarchically, adds tag
names, allows one to construct a style sheet to define the structure of the XML data. There is a family of XMLs for various disciplines (ie math, e-commerce, etc). Perhaps we need one for the
automation industry.

Here are a couple of links to xml info. Warning- drink coffee before reading the second one.

http://www.w3.org/XML/1999/XML-in-10-points
http://www.w3.org/TR/REC-xml

I have used Microsoft SQL server for logging data which can log up to 18 tables worth of data per second from a GE Cimplicity and it works
very well.

Curt Walters
 
M

Matthew da Silva

Joe -- I'm still trying to sort it out too. But AFAIK the thing we call XML is a much tougher nut, than was HTML, to crack. The average person will have more difficulty with XML which resembles
nothing less than an advanced computer language (although is is not).

XML is not like HTML in that sense. Just like CGI (which are mostly written in Perl, essentially a 4GL) XML is not easy to get a hold of. I did some research on the XML deal a while back (in the days of Amazon.com's early rise :)) and as I was downloading these big, fat PDF files of 140 pages, I was thinking golly! who's going to do this for control systems! but, you know, it is possible to write automation using Perl, I think.

With XML, each document defined a part of the specification, say, for online transactions. (When I say specification I mean the meta tags.)

Meta tags are like receptors on a human cell. Without receptors, a virus cannot get a 'hold' of the cell and interact with it. In the absence of correctly-defined 'receptors', complex data files sent via TCP/IP including XML and HTML, with GIF and JPG associated files, will just slide off the target object, and never connect. Thus, no
transaction. No ecommerce. No automation.

For ecommerce to be automatic, these receptors must be defined in such a way as to satisfy both external and internal requirements for data reporting. Those big meta tag definitions basically represent the interface of the external and internal worlds. That's why EDI companies have been morphing into B2B s/w companies.
They're the ones who set up all these networks in the first place. But they don't have a monopoly on the terminology. So, they join what are, in effect, working groups to hash out the details.
Terminology belongs to the public domain. ISA has a role to play here, as do other organizations; and, most importantly, general users.

After completing the internal hashing out of specifications, they can recommend them to the ISO in Geneva and have them published as a standard. It's just like the way it was for fieldbus. That's how it will be for SCADA/XML; IMHO. It's up to the end-users and manufacturers to get involved. For SCADA to work in XML,
somebody's gotta be able to write fifteen, big, thick volumes of specs. Any volunteers?!?!

Matthew Yamatake Tokyo
 
M

Mintchell, Gary (Cahners)

XML is an international standard. Check out http://www.w3c.org. We have written about XML in manufacturing a couple of times lately in Control
Engineering. Check out the Technology Update in the July 2000 issues at http://www.controleng.com. Essentially, XML describes a method of communicating data somewhat like HTML describes graphical pages. The trick
in manufacturing (or any other business or industry) is to devise a commonly agreed upon set of tags so that the information can be read and understood by any number of applications. OPC Foundation has a working group trying to do just that (http://www.opcfoundation.org) by linking XML and OPC. OPC could be used for control level communications with XML the "vehicle" for data communications to ERP and other higher level applications. I took a very good seminar from the local Microsoft people on programming XML. I'm
sure that there are resources locally to most on the List for a quick primer.
Gary

Gary Mintchell, senior editor
Machine and PC-based control, Human Machine Interface
Control Engineering magazine
2000 Clearwater Drive
Oak Brook, IL 60523
(630) 320-7131 Ohio office (937) 498-9431
[email protected]
http://www.controleng.com
 
R

Ralph Mackiewicz

> OPC Foundation has a working group trying to do just that
> (http://www.opcfoundation.org) by linking XML and OPC. OPC could be
> used for control level communications with XML the "vehicle" for data
> communications to ERP and other higher level applications.

Really? I thought that OPC was simply replacing the underlying DCOM method of distributing OPC calls over a network by specifying XML messages that will be transported using SOAP instead. This would presumably involve having OPC specify how to represent a floating point value in XML, an integer, an item name, poll period, etc.

The "vehicle" you refer to requires definition of what floating point values should there be for a bearing temperature monitor (for instance). In other words, not how to represent the value but which values should there be.

This kind of object definition standard requires detailed process knowledge, not comm knowledge, to define. I suppose OPC could act as an umbrella organization to develop such models like EPRI did for the Generic Object Models for Substation and Feeder Equipment (GOMSFE) in the electric utility industry. But this requires detailed vertical
niche knowledge of both users and vendors. Users in the IA industry generally tend to respond to standards, not work on them (of course there are exceptions).

If you are not an OPC member I don't know how you can find out what they are doing. Their "Ask OPC" service seems to be inoperable (the last message answered was dated 12 Dec 1999 2 recent questions of mine have been ignored). Also, I could not find any specific information on what OPC is doing with XML from their web site. It might be there but I gave up after several minutes and there is no site search.

Maybe there is an OPC member on this list that could enlighten us as to exactly what OPC is doing with XML.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
Top