Comments:

Flat Nested Threaded Embedded

Oldest First Newest First

Author	Thread:
Doug Horton	Scope of Bridge Analysis and Design Schema Posted: Monday, November 29, 2004 9:29 AM (EST) The overall approach and plan seems well thought out. I definitely agree that the work done in VIRTIS/OPIS should be the foundation for the schema. My only comment deals with the Sample Applications. Why are the samples limited to prestressed? I personally believe that steel would be a better benchmark due to the added complexity. If there are limitations for each area in terms of time and cost, then prestressed is probably the easiest path. Virginia uses a lot of both steel and prestressed and thus is interested in good data transfer for each.
Loren Risch	Scope of Bridge Analysis and Design Schema Posted: Monday, November 29, 2004 10:34 AM (EST) Personally I would prefer a steel girder bridge but I think the costs are prohibitive.  There are several software vendors and at least one state that have developed prestressed beam software.  Some of it already uses XML.  Most is quite innovative.  I am not aware that XML is used a great deal in the steel software industry.  I may be ignorant of the current situation I think the combination of limited resources plus several innovative concrete software developers make prestressed beam development the best scope.
Jon Lea	Scope of Bridge Analysis and Design Schema Posted: Monday, November 29, 2004 12:23 PM (EST) I think it would be a good idea to step back a bit and consider the short and long term objectives of this project (or at least the potential objectives) before discussing the details of whether the initial subset schema should consider steel or prestress.   XML schemas by themselves don't offer the “guy in the street”, ie., the application developer (state or private) much assistance in sharing data between application A and application B. An XML schema can validate an existing XLM instance document but it won't create one nor will it transfer data from the instance document into a client application. It is a very good starting point just as is a well designed set of C++ engineering or business classes are to the application developer. A poorly designed XML schema will cause similar long term problems as a poorly designed database structure.   However, once the initial XML schema is developed (whatever it may contain) the next step will be very important to the success of the project if once gauges success as “use by others”. Developing a VB application using MS DOM and using the initial schema to validate an XML instance document created by O/V has a couple of unfortunate side affects that should be considered.   1 - It presupposes that the XML created by O/V is compatible with the yet-to-be-developed XML schema which means that the XML schema to be developed will have a “tendency” towards looking a lot like the XML created by O/V. Now if the XML created by O/V is the optimal solution for the new XML Bridge Schema, then great.   2 - The DOM parser reads an XML instance document completely into memory and hands the application developer a very large tree structure and says: “guess what I have just read into memory”. Then the application developer starts posing XPath queries or starts to walk the DOM tree and looks at the nodes of the tree to see if supports are present, beams, materials, sections, etc. This is obviously a very time consuming process and all application developers (state and private) would need to write this same low-level guessing code.   3 - The pilot VB application then will output a text input file for a very specific application (PennDOT PS LRFD). Therefore, the VB application is really a proof of concept application since (hopefully) it will be used to see if the proposed solution is viable but not used in the future. At this point in the project, the application developer (state or private) really only has the initial XML subset schema that can validate an XML instance document created by O/V for prestressed beams and a sample of how to use the DOM to extract information.   In reality, state and private application developers have existing applications that have their own private (native) data structures and they really want to share their data with other applications in the most convenient method possible. The applications are probably written in some flavor of C++ or C (maybe VB) but operate at the domain object level and that is how they want to move their data to and from a neutral file format (this is the XML instance document) so that other applications can use it. Handing them an XML schema and telling them go do it will not create many opportunities for data sharing.   So what should be the next step after developing the new XML schema to represent bridge data? One could answer this question by asking another question: what do we have after we have developed the XML schema? And the answer to this question is that we have another definition of a bridge database. It is not an SQL database definition but it is a definition of the structure of data – and this is the definition of XML schemas.   And what is usually the next step after a database structure has been created? This would be creating a data access layer of code (usually CRUD-type operations) to provide application developers convenient access to the data in a language (I speak bridge here and try to avoid DOM) that they know and shield them from the details of storage. This implies, that yes, the next logical step would be to write a DAL API for the newly created database structure. But you might say that we already have a database API to the O/V database, and yes we have. But this project creates another database definition that needs another API - if the project is concerned with both short and long-term use by others.   Now creating API's can take time but fortunately, there are software tools (free ones also) that can read XML schemas and create C# / C++ classes that can serialize and deserialize themselves to and from XML. This means that the application developer can work at the C# / C++ object level (”IMaterial”, “IBeam”, etc),  creating, reading, updating, deleting objects, and then ask the object model to create the XML or vice-versa, the object model can read an existing XML document and the object model will create itself.   At this point in the project the state and private application developer has a dll containing a basic API that can be used to share data with the new neutral XML bridge file. This project could next use this new API, along with the existing COM-based API, and create an application (or a dll utility) to extract data from the O/V database and create the new XML instance documents compatible with the new XML schema and/or write the input file for the PennDOT prestressed program.   The XML file currently created by O/V for prestressed beams now is not needed (this is good since it looked like it was going to influence the design of the schema) since this VB replacement application/utility uses the existing COM-based API (also good to have another example of how to use that API) and the new API directly. In addition, this VB replacement application / utility will be needed in the future (hence it is not a throw-away proof-of-concept application) since AASHTO needs to have something that will translate data to and from the O/V database and the new XML instance documents.   Just some food for thought - As someone famous one said, the devil is in the details and there is no such thing as a free lunch, there are other things to consider for a production level API.
Doug Horton	Scope of Bridge Analysis and Design Schema Posted: Monday, November 29, 2004 12:50 PM (EST) All of the comments are valid and you have nailed what I agree must be the primary target - getting something that can be used without requiring a great deal of additional development at the local level. Needless to say there will always be work required to enable communication between programs, whether legacy or newly developed. The framework is the key in my opinion and the sooner one is established as a basic standard, the easier it will be to move forward. The easier it is to access and use the framework, the better. I will have to leave it to Loren or another committee member to address whether the methods you outline are within the actual scope of the project as currently established.
Richard Pickings	Scope of Bridge Analysis and Design Schema Posted: Monday, November 29, 2004 3:31 PM (EST) Where’s the Architecture? I agree with Jon that I need to be able to step back a bit in order to see the big picture here.  I have looked over the web site and found documents that describe a coarse overall project vision, an interim report, presentations, and work plans/budgets. What I don’t see is a vision of the overall architecture needed to pull this off successfully. Some questions that I would like to see answered are:   1)      Bridge engineers and software developers are busy people and most will likely have very limited resources (monetary, training, and time-wise) to adopt these schemas. Hence, a low barrier to entry is crucial for the long-term success of this project. Jon’s example of all developers having to write similar DOM code to wade through data is an example of a high entry cost. What steps and technologies do the investigators propose to minimize the cost of entry for outside developers? 2)      My experience developing LRFD software has shown me that every agency has, or will have, its own idiosyncrasies toward analysis, specification checking and bridge description. Hence, even with infinite resources it is practically impossible to design “perfect” data structures. IMHO the best way to solve this problem is to allow end users to extend the schemas locally as needed. Later, a mechanism should be in place to incorporate these extensions into the main schema if desirable. What techniques do the investigators plan to provide extensible schemas, and how can extensions be managed once they are created?   I suspect that many of these issues have been discussed in panel and implementation meetings, and I realize that the discovery phase of the project has recently been completed. However, there must be planning taking place to tie the implementations of the many schemas for this project together so they can be presented in a cohesive manner. As an outside (web-only) reviewer I would like to see documentation for an overall architectural plan in the form of a separate document to be posted in this web site. Is this part of the plan?
Frances Harrison	Scope of Bridge Analysis and Design Schema Posted: Thursday, December 02, 2004 3:00 PM (EST) Thanks for your very thoughtful comments.  Here are some responses, but we'd welcome further input and discussion on these topics... The goal in the bridge area is to make it possible to analyze the same bridge in multiple design packages.  The hypothesis is that this will be accomplished not by writing direct application to application interfaces, but by defining a common XML data structure that multiple applications (both current and potential future) can read from and write to.  This project is primarily about getting this part right, and developing sample applications that provide a proof of concept and some examples for developers that will want to write interfaces to the schema. Once this is done, more work may be required to support and encourage its use.  That is why the project included a task to define an ongoing organizational mechanism to continue work that was begun. With respect to the proposed sample application, the intent is to write a translator from V/O to the TransXML bridge schema and then from the TransXML bridge schema to PENNDOT LRFD.  While we want to build on the content of V/O, we also want to make sure that the TransXML schema for bridge analysis is neutral, i.e. that it is general and flexible enough to be compatible with other bridge analysis software packages.  We really welcome your participation and input into the schema development process in order to make sure that this happens. Regarding the API idea, this may be a logical future acitivity, but I'm afraid this is not this project's charge - we are purposely avoiding selection of particular platforms and staying in the independent and neutral XML world, and focusing on the data content side of things. There are a number of avenues that could be explored for interfacing existing and new systems with TransXML - use of XSLT, existing parsers based on SAX and DOM, web services approach, etc.   While the development of an API could facilitate the use of the schema, the real question is what incentives exist for people to make use of it in the first place - the equation then becomes how valuable it would be vs. how much effort is required to write the interfaces.  There are examples out there (e.g. LandXML) where considerable benefit was derived from a schema that was collaboratively developed (without any supporting API's) - in that case because people recognized the value and chose to write the needed interfaces.
Frances Harrison	Re: Where's the Architecture? Posted: Thursday, December 02, 2004 5:13 PM (EST) 1)  You make very valid points - low cost of entry is a major concern.  But our scope calls for taking a first step - identifying key data exhange requirements, modeling them from a content perspective in UML, developing XML schema that use a consistent set of style conventions and developing sample applications.  We don't have the funding of an effort like Justice XML that took on bigger architectural issues.  We will, however, be defining next steps to be taken after this project concludes, which will include things like tutorials and a broader array of applications that support implementation of the schema.   2) Our goal is to define a common set of data elements that can be shared across applications - not to design perfect data structures that cover the universe of possible attributes.  That said, it would be desirable for individual agencies to develop local extensions and propose these extensions for incorporation into the main schema. We will use a combination of design practices to provide for extensibility - solid UML modeling that will serve as a foundation for the XML schema, identifying common elements across the schema, splitting schema components across documents where it makes sense to promote reusability, and use of various XML Schema constructs (namespaces, wildcards, substitution groups, etc.) to allow people to extend the TransXML schema.   We will be developing a consolidated UML model including all of the schema - that is probably the closest thing to the architecture you are looking for.
Bill Rippey	Scope of Bridge Analysis and Design Schema Posted: Wednesday, December 08, 2004 3:31 PM (EST) a) Overall observation:  statements of areas that will be considered outside the first phase scope may be helpful.   b) Does the Interim Report Document, Nov 5, 2004, supersede the scope statement (July 23) posted on the discussion forum?  c) Interim Report Table 2.1 lists “Bridge Construction”.   Section 2.4  includes “construction”, but I don’t see a specific statement describing on-site or in-shop fabrication (e.g. for welding details).   Should 2.4  include perhaps “…,transfer of bridge design information to fabricators and/or steel detailers?”    E.g. will NCRP 20-70 fabrication and construction definitions be in scope?  Section 4.4 mentions only Bridge Analysis and Design.    Which section takes precendence, Table 2.1, section 2.4 or 4.4?    d) If steel detailing and fabrication will be in scope, then a potential resource would be NIST’s document, A Welding Data Dictionary (in full disclosure, I wrote it, with help from AWS documents).  It can be viewed or downloaded at http://www.isd.mel.nist.gov/projects/awms/.     e) Could the XML appendix to NCHRP Report 485 be posted to the transXML web site?  It was apparently not included in the final document version.
Steve Brown	Scope of Bridge Analysis and Design Schema Posted: Wednesday, December 08, 2004 5:43 PM (EST) Well stated.  Is it intended that the data access layer of code be open and available as part of the TransXML deliverables ? I have been working in both Java and C# and would pose the question of developing the DAL in C# or Java insuch a way that the DAL code base might be transformed between the two closey related programming languages? Just a thought.
Mark Mlynarski	Scope of Bridge Analysis and Design Schema Posted: Thursday, December 09, 2004 5:11 PM (EST) Thanks for your comments. See my responses below. a) c) and d) At this time, the bridge section of TransXML is focusing specifically on prestressed beams. The reasons for this focus are because of the current scope and funding  and because of the availability of existing prestressed software packages (some of which already use xml).   The focus in this initial step will be to transfer input from one design prestressed package to another, produce output, and use TransXML to compare the results.   Ultimately, moving data from the design phase to the fabrication stage is desirable. It is doubtful there is sufficient detail in the design data for fabrication, however,  and the plan is to provide enough extensibility to add this feature in the future.   b) The document on the discussion forum is the most up to date. e) This document has been posted in the 'Bridge Structures->Working Group Documents' section of this web site.
Michael Manore	Scope of Bridge Analysis and Design Schema Posted: Friday, December 17, 2004 5:58 PM (EST) To The Group:   Realizing the scope of this project is to develop Trans-XML schema for the 2D realm of Bridge Analysis / Design, we highly recommend that these schema be developed in a way that they can be leveraged as part of future 3-Dimensional Trans-XML Schema for 3D Bridge Analysis / Design.  The TRB Visualization Task Force has, for a long time, looked to promote better standards for the shareability of 3D and 4D transportation data.....whether is be roadway design, bridge design, related analysis data, traffic data, etc.  The importance is that as bridge design and analysis evolve further to leverage the benefits of designing, analyizing, and communicating through the use of more “VISUAL“ technologies, we will need a standard by which this information can be shared for different environments. i.e.    The data generated as part of a 3D analysis & design of a major interchange, could be leveraged to be placed as part of the 3D design of the roadway of which is is a part......which could then be placed in the 3D community in which the project resides........which could be reviewed by non-engineering stakeholders who have a say in the bridges' location and aesthetics.......the same data which could be leveraged in an emersive driving simulator where a comprehensive human factors assessment could be performed allowing the engineer (and others) to actually drive in this community and develop a driver's perspective assessment on the quality of this bridge design. SUMMARY:  The 2D schema you are working to develop here should be “EVOLVABLE“ to address the future needs of the more emmersive deisgn / anlysis environments of the future.  We'd be happy to provide further insights in this issue as requested.
Stuart Chen	Scope of Bridge Analysis and Design Schema Posted: Friday, December 17, 2004 11:43 PM (EST) The interim report states "We believe that the design-to-construction process is a high priority for TransXML," including construction pay items.  Bridge pay items should be included here.  The interim report also states that XML schema will be developed to "Track installed quantities and materials used and tested during construction."  Detailing and fabrication information management software currently works with such data.  The work that has been done defining data dictionaries with the AISI steel material work, AISC CIS/2 (CIMSteel Integration Standards - which include manufacturing as well as analysis and design) and Rippey's welding data dictionary, all suggest that significant work has already been done relevant to steel bridge structures that would make such bridges a strong candidate for developing schemas to support the design-to-construction process.  Sample applications should by no means be limited to prestressed superstructures.  Nor should they be limited to just making it possible to analyze the same bridge in multiple design packages. Thus, it is rather baffling why the project team is proposing to define the bridge schema scope as limited to just those data items that would support only design and rating operations, and further limiting to just prestressed beams.  Although the OPIS/Virtis object is a logical starting point for the development, bridgeXML by no means should stop there.  In order for the eventual schema to be used, they should not be defined too narrowly.  If project resources are too scant for this, perhaps the project team can convince the project panel to approach SCOR, cap in hand, of a modest funding increment for some work in the design-to-construction process for bridges.
Mark Mlynarski	Scope of Bridge Analysis and Design Schema Posted: Tuesday, January 04, 2005 2:45 PM (EST) Stuart, Our intent is not to stop at the Opis/Virtis object but to use it as a starting point. Project resources are limited for the bridge section and we are trying not to bite off too big of a chunk initially. We do believe the design to construction process is important, but we are somewhat limited in our scope. Our intent is to create a schema that is evolvable so that we can add design-to-construction in the future as funding becomes available.
Mark Mlynarski	Scope of Bridge Analysis and Design Schema Posted: Tuesday, January 04, 2005 2:47 PM (EST) Steve, The code will be included as part of the deliverable, however, the focus of the code will be a demonstration of the schema usage rather than a production level DAL.
Mark Mlynarski	Scope of Bridge Analysis and Design Schema Posted: Tuesday, January 04, 2005 2:49 PM (EST) Our goal is to make the bridge TransXML flexible so that it can evolve with future transoportation developements.
Micheal Watters	Scope of Bridge Analysis and Design Schema Posted: Wednesday, January 05, 2005 3:40 PM (EST) Just an F Y I.  Wyoming DOT has embarked on a complete rewrite of the BRASS-GIRDER and BRASS-GIRDER(LRFD) programs (which are the engines of Virtis and Opis).  We are combining the two programs and have looked into incorporating XML into the development.  We have not made any commitment to doing this yet.  If we did, there would be a good chance that a translator would not be needed between V/O and TransXML.  We have not looked at the TransXML schema yet, but plan to do so soon. Regarding the choice between starting with a prestressed girder vs. a steel girder, this merger process is concentrating on steel girders first with a beta release being planned for the end of this year.  I do not know if this would affect your decision, but I wanted to let you know our plans.
Al Butler	Scope of Bridge Analysis and Design Schema Posted: Tuesday, January 25, 2005 10:49 AM (EST) It appears from the discussion posted to date that there is a little question regarding the evolving scope of the project, with budget restrictions being somewhat responsible.  As with the entire set of XML profiles being explored by TranXML, the reason for the data exchange (i.e., the application) is the part that must be well defined.  If I may, I suggest a possible approach is to do a broad high-level effort that describes the data needs and models for all types of bridges, and then defines a base architecture and selects one or more types for detailed work as a fist cut XML implementation.  Essentially, what I am suggesting is that a complete overarching data model be developed, with one or more bridge-type XML profiles being devised that adopt the central common elements for all bridge types plus the special needs of the selected type(s). Jon is quite right that an XML standard offers, at best, a message format, not an API definition.  Data exchange standards, like TransXML, form a technical solution, but we repeatedly read articles showing that our primary impediments to data exchange are organizational.  Take, for example, the recently completed draft and review process for the new national standards developed by the Geospatial One-Stop (GOS) initiative and now being promulgated through the FGDC.  Scores of us toiled for a full year to get a set of draft documents describing the seven National Spatial Data Infrastructure (NSDI) themes.  All of 30 people actually read the drafts and submitted comments out of more than 50,000 potential users who were personally invited to participate. The fundamental flaw with standards is that very few of us do anything in a standard way.  (Use of common design software helps.)  The basic problem faced by data sharing entities is making their databases look alike.  I say a good pavement condition is 5; you say it is 1.  My state conveys property using metes and bounds; your state uses the Public Land Survey System.  My street address field has 20 characters; yours has 35.  Conceptually, having a national standard provides a universal translator.  Make your data look like the standard and you’re home free.  Only it’s not so free to convert your data to a standard, especially when the benefits of doing so flow to others. What we need to work on are not data exchange standards, but data exchange reasons that get to the heart of our organizational resistance to data exchange.  I have often said that the only people motivated to exchange data are those who don’t have any.  Give me a good reason why I should expend part of my budget to make it easier for you to do your job.  Of course, lowering the cost of data exchange will make it easier to overcome organizational barriers.  TransXML may offer a reasonable way to make it cheaper and, thus, easier for me to convince my clients to adopt national standards. We will all need to be able to make a business case to senior agency managers to get TransXML or any other standard adopted.  We will have to show what the agency gains for its expenditure to reach compliance.  Frankly, sharing data with others is not an obvious strong point.  We need to be able to show lower cost designs through data exchanges between agency and consultant, or from design to construction.  Is anyone including the marketing task in the scope of work?