I believe my issue is stemming from the SignedInteger type, which I cannot find
any reference of outside of the Daffodil source (so I assume is one of the
extra nodes you refer to.
In particular, the definition of SignedInteger is:
protected sealed trait SignedIntegerKind extends SignedNumeric.Kind
case object SignedInteger extends TypeNode(SignedNumeric, List(Integer)) with
SignedIntegerKind {
type Kind = SignedIntegerKind
}
Which indicates that we should have the type hierarchy:
SignedNumeric
|
SignedInteger
|
Integer
However, Integer, Decimal and SignedNumeric say:
case object Integer extends PrimTypeNode(Decimal, List(Long,
NonNegativeInteger)) with IntegerKind {
type Kind = IntegerKind
override def fromXMLString(s: String) = new JBigInt(s)
}
case object Decimal extends PrimTypeNode(SignedNumeric, List(Integer)) with
DecimalKind {
type Kind = DecimalKind
override def fromXMLString(s: String) = new JBigDecimal(s)
}
case object SignedNumeric extends TypeNode(Numeric, List(Float, Double,
Decimal, SignedInteger)) with SignedNumericKind {
type Kind = SignedNumericKind
}
Which suggests a hierarchy of
SignedNumeric
| |
Decimal , ....., SignedInteger
|
Integer
So the relationship between Integer and SignedInteger is inconsistent.
SignedInteger believes itself to be a supertype of Integer, but Integer does
not believe itself to be a subtype of SignedInteger
Skimming through the codebase, it is not clear to me what the purpose of
SignedInteger is. Under the standard XSD definition, xsd:Integer is already a
signed type. And, apart from introducing itself (inconsistently) to the type
hierarchy, the only usage I can find is in the guard of a case structure, wher
I believe we should be able to replace it with just Integer and not change any
result
Having said all of that, my problems go away if I replace SignedInteger with
Integer in the code I am adding with just Integer. This is consistent with my
hypothesis that SignedInteger is never actually used (beyond as a glorified
alias to Integer in the scala type system).
________________________________
From: Beckerle, Mike <[email protected]>
Sent: Friday, April 12, 2019 7:21:52 PM
To: [email protected]
Subject: Re: NodeInfo confusion
Type system matches the dfdl/XML schema type system, not the scala type system,
but has some extra nodes that are there for convenience also.
In dfdl/XML decimal is super type of integer.
Get Outlook for Android<https://aka.ms/ghei36>
From: Sloane, Brandon
Sent: Friday, April 12, 6:17 PM
Subject: NodeInfo confusion
To: [email protected]
I am looking at the type hierarchy defined in NodeInfo and am confused about
the Integer type. In NodeInfo.scala we have: protected sealed trait IntegerKind
extends SignedInteger.Kind case object Integer extends PrimTypeNode(Decimal,
List(Long, NonNegativeInteger)) with IntegerKind { type Kind = IntegerKind
override def fromXMLString(s: String) = new JBigInt(s) } In the above code, the
second line declares that Decimal is the parent type of Integer. However,
within the scala type-system, SignedInteger is the supertype of Integer (as
declared in the first line). My understanding is that the type hierarchy of
NodeInfo is intended to match their Scala type hierarchy. The context where
this is coming up is that I need to find a type that will serve as a supertype
(in the sense that NodeInfo defines) for all integer types. Brandon T. Sloane
Associate, Services [email protected] | tresys.com
