You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@daffodil.apache.org by "Mike Beckerle (Jira)" <ji...@apache.org> on 2022/01/05 17:47:00 UTC

[jira] [Created] (DAFFODIL-2620) Redesign runtime 1's nextElementErd()

Mike Beckerle created DAFFODIL-2620:
---------------------------------------

             Summary: Redesign runtime 1's nextElementErd() 
                 Key: DAFFODIL-2620
                 URL: https://issues.apache.org/jira/browse/DAFFODIL-2620
             Project: Daffodil
          Issue Type: Improvement
          Components: Back End, Middle &quot;End&quot;
    Affects Versions: 3.2.1
            Reporter: Mike Beckerle


The conversion of textual representations of Infosets (such as XML or JSON) requires converting local name+namespace into an ERD. 

This currently depends on a data structure called the 'TRD Stack' which must be carefully maintained by the runtime. Each term on the TRD stack has a PartialElementResolver and the first such on the TRD stack which resolves the element "wins" and provides the ERD. 

This algorithm enables shared group definitions, and shared complex type definitions (which implicitly contain shared group definitions), to have different resolution of elements based on the specific context where they are used. 

For example, suppose a shared sequence group contains an optional element child named C. Suppose it is used in two different places, one where the shared sequence is followed by a required element named A, the other a required element named B. 

Then at runtime, in one context, the nextElementErd() will consider the possibility of either C or A, the other context the nextElementErd() will consider the possibility of C or B. C will be the term on top of the TRD stack, and in the first context, the next thing on the TRD stack will be the term containing A. In the other context the next thing on the TRD stack will be the term containing B. By chaining down the stack calling each PartialElementResolver, we're able to have a compiled data structure for our shared sequence group which is context independent, and so can in fact be shared.

However, there is much complexity here. 

Each point-of-use of a shared component contains two aspects. The shared aspect, and the specific-to-that-point-of-use aspect. By associating the nextElementErd() data structures not with the shared aspect, but with the specific aspect, the need for the TRD stack can be eliminated, replaced by a static data structure. 

 



--
This message was sent by Atlassian Jira
(v8.20.1#820001)