finite element modeling Markup Language   

Home
Site Map
Feedback


 

Specification

Back Up Next

  
About
Specification
Documentation
Download
FAQs
MatML
XML links
Contact
o

Issues UMLspecification of DTDs Examples Station-To-Station
 
     Issues

Introduction:

    The distance to be traveled for the development of a comprehensive femML standard is very long. Experience from other efforts has shown that on one hand no specification can end up becoming a standard if it does not have the support of industry, government, and academia. On the other hand experience has also shown that no standard is any good if it is not used by end-users in all of these sectors.

    In addition to the economic and political factors that play a role in developing and adopting standards there are always technical reasons mostly associated with the derivable utility, that can make or brake a standard. The technical issues that we can foresee that will play an essential role in femMLís adaptation and usage are the following:

 

Scale of Generality:

     Should we be thinking in extending femML to cover finite difference discretizations with all their idiosyncrasies, boundary element discretizations, hybrid discretization or even non-discrete models of continuous systems. For that matter should we be thinking of a femML or discrete model representation Markup Language (dmrML), or even a "physical model behavior representation Markup Language" (pmbrML)? It appears that the latter would be the most inclusive and general . However, very ambitious goals may provide all kinds of reasons for not realizing these goals. This is an issue that a decision cannot be taken a-priori before considering resources and support.

 

Separation between Appearance and Behavior:

     The current DTD implementation (v. 1.02) follows a strict FEM data file structural architecture. Information holding the geometry information of the 3D model is included along with loading, material and results specification. However, there are reasons for altering this situation. If we consider that there might be cases that the data that need to be exchanged are going to be based only on a particular subset of the original, then we have consider structuring the file in such a way that is easier to access and transfer data subsets of particular nature. The geometry model that is responsible for the appearance of the model, and the loading, material and results specifications that capture the behavior part of the model are two subsets of this type. The question at issue is under what conditions should we restructure the DTD to attach them under separate elements in order to facilitate transformation? In view of the existence of X3D and XSIL a direct mapping between their elements and the geometry elements of our DTD could be possible. The disadvantage of overextending such an approach may lead to a very verbose data file. However, since files like this are not intended to be human readable (although it actually is) but rather machine-readable. This issue will most likely be resolved from the need to integrate horizontally with other industries (i.e. entertainment industry) that may require CAx models. The alternative version v. 2.99b is attempting to address this issue.

 

Leveraging of existing XML dialects:

     Particular element definitions (i.e. material definition) may already be defined from an already existing XML application (i.e. MatML). The namespace specification allows borrowing such constructs. The question is when we should be doing it when we should not.  This issue can be resolved careful consideration of the semantic overlap and proximity between the intension of our application and the extension of the existing dialectís DTD.

 

Scene graph Structure for geometry:

     How much should we be aware and should we implement scene-graph internal representation architecture, that follows the lessons for other 3D representation methodologies such as Open Inventor, VRML and X3D. What may determine a settlement to this issue may become a mute point when efficient ways to go in and out from the scene-graph representation become available while at the same time do not require users to spend time over steep knowledge curves. However, our group believes in leveraging existing technologies and lessons learned from their usage to make decisions about our contribution to the evolution of femML.

 

Composition and factoring isomorphism between data of FEM model and their femML expression:

     In the physical space structures can be thought as aggregates of parts and components. What allows us to synthesize a complex structure out of various parts is called composition of parts. When we decompose the aggregate structure to its parts we perform the operation of factoring. We can obviously think of both of these operations at the data representation level where femML documents can be the result of composing other ones (corresponding to part descriptions), or femML documents corresponding to part representations can be the result of factoring aggregate structures femML representations. The issue here is how much should we strive to establish and maintain a DTD/Schema architectures that preserves a on to one correspondence between the physical and data representation of the abilities to compose and decompose FEM representations.

 

Distribution of metadata:

    Should a document created as the composition of other documents that correspond to parts, components or substructures, carry the meta-data of the sources? If yes, should they also be composable or should they exist individually as a part of metadata nodes at lower levels of the DTD graph?

 

^ Return to Top of the page

   
   UML specification of the DTDs
Introduction: Universal Modeling language has been proven to be a natural tool for capturing the tree structure of any XML or DTD document. In that spirit 

 

femML 1.02 DTD

 

femML 2.99b DTD

^ Return to Top of the page

  
   Examples
Introduction: A set of examples and custom tools that facilitate the usage, understanding and evolution of the specification.

V. 1.02  Example:  Forthcoming.
 V. 2.99b  Example:  Forthcoming.

^ Return to Top of the page

 
    Station To Station (S2S) approach
Introduction: Despite the benefits of extending the expressive power of XML with the dynamic data representation and manipulation capability of Java enabled applications, we have decided to focus onto the simplest of the approaches for exchanging FEM model data, by utilizing the Station-to-Station (S2S) approach that is built entirely on XML technology.

 

Schematic:

 Description:

This decision does not preclude the future exploitation of the XML-to-Java (or vice versa) cooperative benefits in terms of dynamics, scalability, deployability and economy.

The S2S model assumes the existence of a source and a destination data-document and it is not different than the most generic of the business to business (B2B) models that dominated the Internet during the last few years.

The transformation can be either implemented trough a common XSLT processor or through a Java application that utilizes the parsed DOM equivalent of the source document structure and subsequently rewrite it to a new one that can then be converted to the target document.

In either case, the transformation processor requires a transformation definition defined via a set of transform functions that may or may not implement templates, while at the same time it ensures that both source and target documents/files are valid according to their corresponding DTDs or Schemas. The transformation can be implemented in a multidirectional manner. Users with not extensive XML or/and Java experience can use of the shelve tools to construct the transformation engines as a byproduct of utilizing intuitive tools with simple graphical user interfaces (GUIs).

^ Return to Top of the page

 

 

Back ] Up ] Next ]

 

Copyright 2002 www.istos.org

 

Page last edited on05/20/2002