Re: [foxboro] client server

I favor XML for the following reasons.

Using XML would give users and Invensys great flexibility.

The database schema (control scheme) could be represented within the XML
itself. This is difficult to do in flat files or csv files.

You could include sequence source, plb ladders and binary data in XML if
needed. This could all be stored in a single file using XML. The whole
control scheme including source, ladders and binary data. It would take
many files to do this with flat files.

Data validation is standardized and documented (DTD, XML Schema).

Invensys would not be bound to any particular SQL Server database schema
so they could improve the database if needed and since XML allows them
to export the schema information anyway then tools could be designed to
adapt to changes based on the use of DTD or XML Schema files.

Excel will import XML files directly as will SQL Server so it would seem
to provide a good way to transport the data from IEE to any user using
modern database or productivity tools.

It sounds like the IEE data tables will be of little use without the
data structures used to store the data. If Invensys is using blobs to
store data objects then direct access to the tables won't help you much.

If we really need flat files then create a filter to pipe the XML to
which outputs the flat files of your choice.

Ted Jirik
Real Time Solutions



Johnson, Alex P (IPS) wrote:
> Re: We are not discussing whether the IEE database should be written to
> use
> SQL or XML.  We are voting to decide what our report format should be.
>
> Voting may be a bit strong, but we are definitely considering data
> reporting formats for the IEE and want informed opinions like those from
> this group.
>
> IPS reserve the right to do something arbitrary and unreasonable if we
> so choose. :)
>
>
> Re: That is a tougher question.  Is SQL still the logical choice, if the
> core data is in XML?
>
> The core data is in a SQL Server database, but the entities of interest
> are stored as a control scheme not as individual blocks. For that
> reason, we need a reporting mechanism and a report format or formats.
>
>
> Regards,
>  =
>
> Alex Johnson
> Invensys Systems, Inc.
> 10900 Equity Drive
> Houston, TX 77041
> 713.329.8472 (voice)
> 713.329.1700 (fax)
> 713.329.1600 (switchboard)
> alex.johnson@xxxxxxxxxxxxxxxx
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Jones, Charles R. (Chuck)
> Sent: Monday, March 26, 2007 12:41 PM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] client server
>
> I vote for standardized, non-proprietary SQL tables.
>
> I understand the motive for asking for Delimited ASCII.  But, my
> personal perspective is that I didn't write the tool that I use now for
> harvesting ASCII data.  It wouldn't bother me if someone else wrote the
> SQL query interface tool.  I would tell the interface what I was looking
> for and it would spit out the data in a spreadsheet or ASCII, whichever
> I wanted that day.  If I wanted more than that, I could flex a few brain
> cells, kill a couple pots of coffee, and come up with my own interface.
> To paraphrase Jeremy and Tom, with SQL tables we could have everything
> we have today and more.
>
> I don't know enough about XML to say much about it.  It is supposed to
> be an open standard.  Is it really?  I mostly hear Microsoft beating the
> XML drum.  HTML is supposed to be an open standard too.  But, MS
> "embraced and extended" it so that web pages built with their tools
> would break if opened by anyone else's browser.  But, I digress... =3D20
>
> We are not discussing whether the IEE database should be written to use
> SQL or XML.  We are voting to decide what our report format should be.
> That is a tougher question.  Is SQL still the logical choice, if the
> core data is in XML?
>
>
> Chuck Jones
> Automation Technologist
> Tate & Lyle -- Lafayette Plant
> Office 765.477.5324 | Cell 765.586.5290
>
>
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Brazell, Troy L Jr
> Sent: Monday, March 26, 2007 11:10 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] client server
>
>
> I have to agree with Mr. Hurwitt. Even though SQL and XML files are fine
> with me, I have a lot of folks that would find Delimited ASCII files
> with headings easier to use.
>
> **************************
> Troy Brazell
> DCP Midstream
> ISA CCST
> Sr. Process Control Analyst
> Office 405-263-4130
> Cell   405-301-2994
> tlbrazell@xxxxxxxxxxxxxxxx
> **************************
> -----Original Message-----
> From: foxboro-bounce@xxxxxxxxxxxxx [mailto:foxboro-bounce@xxxxxxxxxxxxx]
> On Behalf Of Gregory A Hurwitt
> Sent: Monday, March 26, 2007 9:04 AM
> To: foxboro@xxxxxxxxxxxxx
> Subject: Re: [foxboro] client server
>
> Jeremy Milum wrote on 03/25/2007 09:15:24 PM:
>
>   
>> On 3/23/07, Johnson, Alex P (IPS) <alex.johnson@xxxxxxxxxxxxxxxx>
>>     
> wrote:
>   
>>> Let's assume that we arrange to allow a command to publish the data
>>>       
> in
>   
>>> the configurators database. What format(s) should we consider?
>>>
>>> 1)    SQL Tables
>>> 2)    XML files
>>> 3)    Excel workbook
>>> 4)    Delimited ASCII files with headings
>>>       
>> SQL Tables.
>>
>> If we have access to a truly relational database model of the
>> configuration data, we can easily transform it into any of the others,
>> but the opposite is not true.
>>     
>
>   
>> An Excel workbook would be the least favorable.
>>     
>
> I disagree.  I personally don't have access to or knowledge of SQL
> tools.
> Also, the database in this case is pretty much a flat file, isn't it?
>
> I'll be working with the data in Excel.  I'm happy to take the data in
> delimited ASCII so others can also easily use their tool of choice.  My
> vote is for #4.
>
> Greg Hurwitt
> BASF Freeport
>
> =3D3D20
> =3D3D20
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
> =3D3D20
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         =3D3D
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Djoin
> to unsubscribe:      =3D3D
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3D3Dleave
> =3D3D20
> =3D20
> =3D20
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
> =3D20
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Djoin
> to unsubscribe:
> mailto:foxboro-request@xxxxxxxxxxxxx?subject=3D3Dleave
> =3D20
> ************************************************************************
> ***=3D
> **************************
> This email and any files transmitted with it are confidential and
> intended =3D
> solely for the=3D20
> use of the individual or entity to whom they are addressed. If you are
> not =3D
> the intended=3D20
> recipient or the person responsible for delivering the email to the
> intende=3D
> d recipient, be=3D20
> advised that you have received this email in error that any use,
> disseminat=3D
> ion,=3D20
> forwarding, printing, or copying of this email is strictly prohibited.
> If =3D
> you have received=3D20
> this email in error please notify the sender immediately. Please note
> that =3D
> we reserve=3D20
> the right to monitor and read any emails sent and received by the
> Company i=3D
> n=3D20
> accordance with and to the extent permitted by applicable legal rules.
> ************************************************************************
> ***=3D
> **************************
>  =
>
>  =
>
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>  =
>
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Djoin
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=3Dleave
>  =
>
>
>
>
> Confidentiality Notice:
> The information contained in this electronic message and any attachment(s) =
> to this message are intended for the exclusive use of the recipient(s) and =
> may contain confidential, privileged or proprietary information. If you are=
>  not the intended recipient, please notify the sender immediately, delete a=
> ll copies of this message and any attachment(s). Any other use of the E-Mai=
> l by you is prohibited.
>
>
>  
>  
> _______________________________________________________________________
> This mailing list is neither sponsored nor endorsed by Invensys Process
> Systems (formerly The Foxboro Company). Use the info you obtain here at
> your own risks. Read http://www.thecassandraproject.org/disclaimer.html
>  
> foxboro mailing list:             http://www.freelists.org/list/foxboro
> to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
> to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave
>  
>
>
>   
 
 
_______________________________________________________________________
This mailing list is neither sponsored nor endorsed by Invensys Process
Systems (formerly The Foxboro Company). Use the info you obtain here at
your own risks. Read http://www.thecassandraproject.org/disclaimer.html
 
foxboro mailing list:             http://www.freelists.org/list/foxboro
to subscribe:         mailto:foxboro-request@xxxxxxxxxxxxx?subject=join
to unsubscribe:      mailto:foxboro-request@xxxxxxxxxxxxx?subject=leave

Other related posts: