Guido van Rossum (the inventor of the Python language) made a couple of
interesting and relevent comments, in a discussion about configuration
languages (which is what DBD and DB files are):
> I certainly didn't propose XML as an alternative. I find XML
> inappropriate when a human has to edit it (except in emergencies).
>
> The alternative I was thinking of was a lot lighter on distracting
> punctuation than XML.
and
> I don't know if it matters much, but I understand most XML
> styles have more text in the data and rely much less on attributes.
Rees, NP (Nick) wrote:
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:
Your use of an attribute for the field value doesn't permit a field to
be a structure containing sub-fields, which themselves may be
structures. This is a major requirement in V4, and the only way to do
that in XML would be for the field value to be text instead of an
attribute. This adds a little more line noise (punctuation) to your example:
<record type="ai" name="my:record">
<field name="INP">#C1 S2@</field> <!-- would change for V4-->
<field name="DTYP">Xycom 566</field>
<!-- 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>
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 too simple to be of much use.
What are the requirements that we're not meeting right now? I'm happy
to discuss and change the info definition to make it more useful, if you
let me know what you want to be able to do with it.
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.
At APS we probably have at least 6 different ways in which DB files get
generated, using VDCT, GDCT, JDCT, Perl scripts, shell scripts and hand
editing. The latter is still very common, and not just among the main
core developers. I expect developers to want to carry on using their
favorite tools to generate application databases, and other people's
experience (not just Kay's) has shown that XML is not a good choice for
files that humans have to create by hand or read.
On a related note, there are currently no special tools for creating DBD
files, and I very much doubt that the frequency with which new record
types get created would justify writing a special tool for this purpose.
I do not want to make developers write DBD files by hand in an XML
format, and the parser for our current DBD file format can be written in
a reasonably small number of lines of Perl (in V4 the IOC will not parse
DBD files at all, the information from them will be converted into C/C++
code and compiled).
I did look at the possibilities of using XML some time back, and I don't
see it as impossible for someone to create an additional DB parser for
iocCore to allow XML databases to be loaded. However there is at least
one reason that I think justifies the inclusion of another parser; it
involves conversions between strings and structures for Channel Access
clients: In V4, all CA traffic will be passed over the network in the
native type of the server channel, thus conversions from the data type
the client presents and the server's type must take place in the CA
client library. We also want to allow clients to be able to read or
write whole structures, and thus we have to have a parser in the CA
client library that can understand a hierarchical data structure value
when expressed as a string, and convert it into a structure for onward
transmission to the server. My current design for the V4 DB file format
is intended to make use of the same parser, so you can use exactly the
same syntax for the value of a field in the DB file that you do from a
command-line CA utility. I really don't want the string format we use
there to be XML:
% caput anj:mystruct "<struct><field name="a">10</field><field
name="b">20</field></struct>"
vs
% caput anj:mystruct "{a=10; b=20}"
- Andrew
--
English probably arose from Normans trying to pick up Saxon girls.
- Replies:
- Re: V4 database definition files Benjamin Franksen
- References:
- RE: V4 database definition files Rees, NP (Nick)
- Navigate by Date:
- Prev:
Re: V4 database definition files Benjamin Franksen
- Next:
Re: V4 database definition files Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: V4 database definition files Benjamin Franksen
- Next:
Re: V4 database definition files Benjamin Franksen
- Index:
2002
2003
2004
<2005>
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
| 
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·