Geoff, et al.,

I have the following comments on this excellent proposal:

1) I still don't see the need for a "typeArray" attribute.  The presence
(or absence) of "dimensionDef" is sufficient for any parser to determine
the size of any array that may be present.

2) As far as using "typeArray" to help if there is a MathML calculation
(since MathML uses vector, matrix type attributes), I don't think this
solves anything because what if the typeArray said "vector" but there
were two <dim> in the <dimensionDef>?  Or what happens if it is a 3 (or
more) dimensional array?  Also, the MathML has the whole <matrix>
<matrixrow> ... <matrixrow/> syntax that we don't want to get into
here...

3) As far as "typeData", I would suggest adding an explicit "boolean"
type in addition to the real and integer.  While nominally covered by
"typeData" with a "base" of 2, it is (or could be) such a common item
that it would be useful to be more explicit.  I'm not as sure whether to
use something separate, or use the MathML <true/> and <false/> for the
values.

4.0) I hope that this section from your example:

    <dimensionDef>
      <dim>3.0</dim>
    </dimensionDef>

doesn't mean that there are non-integer dimensions!  It's been too long
since I studied fractals, but I don't recall anything that would be too
useful in DAVEML-type simulations. :-)

http://en.wikipedia.org/wiki/Fractal
http://en.wikipedia.org/wiki/Fractal_dimension


Dennis
---
Dennis J. Linse, Aerospace Engineer
Science Applications International Corporation
+1-703-294-4449  <mailto:[EMAIL PROTECTED]> 
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brian, Geoff
Sent: Thursday, March 27, 2008 2:01 AM
To: Aerospace Sim Standard discussion group
Subject: FW: arrayDef & draft simstd comments 

 
Hi all,

The following is an experimental scheme I have come up with that makes
minimal change to the dtd to add a capability for vector/matrices. The
major change is to the definition of the variableDef element.

I have added to following in the element definition:
 "dimensionDef?, (calculation | array)?"

Also I have added to following in the attribute list:
     typeData   (real | integer) #IMPLIED
     base       CDATA   #IMPLIED
     typeArray  (scalar | vector | matrix)      #IMPLIED"


The "dimensionDef" is used when listing the dimensions of the
vector/matrix.
The "array" is used to represent the associated data table for the
vector/matrix.

The "typeData" and "base" have been included to address Giovanni's wish
to have data types for each variable. This concept I have taken from
that used by MathML for the definition of "cn" and "ci" elements. The
"typeData" is a subset of that defined in MathML (having the
possibilities of integer | rational | complex-cartesian | complex-polar
| real | e-notation  [Default : real]). The "base" has an integer value
of between 2 and 36, with a default of 10.
The "typeArray" attribute is used to define whether the variableDef
represents a scalar value, or vector/matrix values. This is again
similar to the convention used by MathML for the "ci" element.

<!ELEMENT variableDef 
     (description?, 
     (provenance? | provenanceRef?)
, dimensionDef?, (calculation | array)?, isOutput?, isState?,
isStateDeriv?, isStdAIAA?, uncertainty?)
>
<!ATTLIST variableDef
     name       CDATA   #REQUIRED
     varID      ID      #REQUIRED
     units      CDATA   #REQUIRED
     axisSystem CDATA   #IMPLIED
     sign       CDATA   #IMPLIED
     alias      CDATA   #IMPLIED
     symbol     CDATA   #IMPLIED
     initialValue       CDATA   #IMPLIED
     typeData   (real | integer) #IMPLIED
     base       CDATA   #IMPLIED
     typeArray  (scalar | vector | matrix)      #IMPLIED
>

To support this, the following is also required.

<!ELEMENT dimensionDef 
     (description?, dim+)
>
     
<!ELEMENT dim (#PCDATA)>

<!ELEMENT array (dataTable)>

My syntax may not be totally correct. I have attached a sample file on
how vector/matrices might look in XML using this scheme.

Supporting whatever scheme is agreed on through Janus will be the next
challenge.

Geoff



IMPORTANT: This email remains the property of the Australian Defence
Organisation and is subject to the jurisdiction of section 70 of the
CRIMES ACT 1914.  If you have received this email in error, you are
requested to contact the sender and delete the email.


Reply via email to