Experimental Physics and
Industrial Control System

"Rees, NP \(Nick\)" <[email protected]> · Thu, 27 Oct 2005 18:03:03 +0100

All,

Thanks for the responses. My take is:

1. I agree with using schema's not DTD's, but you can even use both at
once. DTD's are good for the element hierarchy, and schema's are good
for data, but can do both.

2. My trivial example would probably not be like Kay's, I would put all
the information in attributes, not as free-form data. For example:

<record type="ai" name="my:record">
    <field name="INP" value="#C1 S2@"/>  <!-- Which, since it is a link
would change for V4-->
    <field name="DTYP" value="Xycom 566"/>
    <!-- And, for instance: -->
    <dct_data>
      <position x="1234" y="4321"/>
      <color foreground="brown" background="yellow">
    </dct_data>
    <archive name="fast" group="mygroup" rate="monitor"/>
</record>

I think this fits the V3 db definition more cleanly (i.e. the converter
is probably a few lines of awk) and in fact I don't think this is really
any less readable than the current format. However, the bonus for me is
that I can define extra tags that I know will be ignored by systems that
don't understand them as long as they validate. My problem is really
that the info item just is to simple to be of much use.

3. As to Kay's "well, why not XML" point, I agree that this is often a
reason, but at heart this is because we are now accepting that we don't
have to write parsers anymore and/or use lex and yacc. Overall, I
believe this is a good thing. In my experience this turns into a bigger
advantage when these files essentially become interface definitions
between isolated components, and we have a schema which automatically
validates the interface. This eliminates a lot of discussion late on in
a large, distributed project. So, I don't expect users to come into my
office to thank me for using XML. I don't expect my users to even know
I'm using XML.

4. Finally, I accept Pam's point that the latest version of most of this
information should reside in a relational database. However, systems
often require information to be stored in many forms - and a textual
form is usually always one of them. This is the subject I am trying to
address. Lets face it, a lot of the code we write is just converting
information into different formats. If you compare text and relational
databases it is more difficult to use source code control on relational
databases, and you still need a way of encoding data for transmission
between applications - this is easier to debug if it is textual. As a
current example, the latest stuff Matej has done on VDCT has involved
cutting and pasting databases in text form via the clipboard. This will
allow Don Dohan to copy an EPICS database out of his relational database
onto the system clipboard and then paste it into VDCT so he can see how
the links work. If you follow this path a little way, we might be able
to do the same for the wiring information in Don's database - if we
agree on a common schema, VDCT could start plotting the 120 volt power
hookups as well. I am just dreaming here, but in doing so I am trying to
convey the reason. This is not just about the definition of IOC
databases anymore, I am trying to invent a world where we have a fairly
flexible (i.e. extensible) data interchange format of which the IOC
database is only a part. I hope this also addresses Kay's concern that
XML hasn't made his life easier. I really starts leveraging itself if
you use it as an information interchange format that we can all agree
on. Using just for configuration of a single application is not its main
justification.

Cheers,

Nick Rees
Principal Software Engineer           Phone: +44 (0)1235-778430
Diamond Light Source                  Fax:   +44 (0)1235-446713

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System