I think DState was the "DPath" state, intended to be the part of the state used for the DPath evaluation.
The notion was that there are all these components of the state that are used by one or another part of the system, and they should be defined there and be the business of that part. I think DState has a back-reference to the greater state object, because the boundary wasn't quite so clean. Also for unparsing, the UState that gets passed along forever is the UStateMain, and all the other UState objects created when we create suspensions for later evaluation have a pointer to that one, used to get the global stuff. So even a suspension can get at the "root" of all UState info. ________________________________ From: Sloane, Brandon <bslo...@tresys.com> Sent: Monday, April 1, 2019 5:25:00 PM To: dev@daffodil.apache.org Subject: Re: Accessing schema information from runtime system Thanks, I see that I can get to the SchemaSetRuntimeData through a ParseOrUnparseState with state.dataProc.get.ssrd Am I correct in my reading of the code that there is not currently a way to get to it through a DState object? I assume the reason that DState does not have a complete reference to the ParseOrUnparseState is related to suspending unparse; and that (since the mapping is static) there shouldn't be any issue in my adding a pointer to it in DState? ________________________________ From: Beckerle, Mike <mbecke...@tresys.com> Sent: Monday, April 1, 2019 5:03:43 PM To: dev@daffodil.apache.org Subject: Re: Accessing schema information from runtime system The lookup table should become part of the SchemaSetRuntimeData. That way it is global to all. Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Sloane, Brandon <bslo...@tresys.com> Sent: Monday, April 1, 2019 4:43:18 PM To: dev@daffodil.apache.org Subject: Accessing schema information from runtime system As part of the enum support proposal (https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Feature+to+support+enumerations+and+typeValueCalc), there is a need to lookup types by qname from within the runtime system. For instance, suppose the schema defined the following simpleType: <xs:simpleTypename="IntToString" dfdl:repType="tns:uint8"> <xs:restriction base="xs:string"> <xs:enumeration value="A" dfdl:repValues="0" <xs:enumeration value="B" dfdl:repValueRangess="1 255" </xs:restriction> </xs:simpleType> In addition to using the lookup table by creating an element with type tns:IntToString, it is also possible to utilize it from a DFDL expression: { dfdl:inputTypeCalcString('tns:IntToString', x) } Normally, this expression would get compiled during compile time, which means we can (in principle) just do the lookup then. However, it is also possible that the debugger will be asked to evaluate this epression at runtime; at which point I do not believe we currently preserve the information needed to lookup tns:IntToString (in fact, even the function defined by tns:IntToString passed to the runtime once per element that uses it, which is potentially 0 times). As an added complication, because of the need to support compiling expressions at runtime, there is not currently an easy way to pass in the schemaSet needed to do the lookup to the compiler even at compile time (since the signature of the compile function is defined in the runtime subsystem). To resolve this, I am thinking that we pass a mapping of (QName -> TypeValueCalculator) that contains all of the types which define such a conversion into the runtime system. However, I am unsure of where we would pass in such a global mapping, as it seems wasteful to pass in the same mapping for every element (as it stands, the debugger gets its dpathCompileInfo from the runtimeData of the currentElement, but duplicating all of the typeValueCalc functions on every element seems excessively wasteful). Brandon T. Sloane Associate, Services bslo...@tresys.com | tresys.com