| |
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 |
