GLOBALS/TEMPLATE vs TABLE_MAPPING/TABLE_RAW_TEMPLATE

[lmichel]

No description provided.

[lmichel]

The question is to know whether we have to allow or not multiple GLOBALs elements

• PRO:
  • this allow the put the right thing at the right place
  • None is forced to use multiple GLOBALs
• CON:
  • This makes thinks a little more difficult for the parsers
  • This makes thinks a little less straightforward for the annoters
  • The meaning of GLOBAL@ID is not clear and may confuse reference resolvers

[mcdittmar]

As far as I can tell, the requirement behind the multiple GLOBALs is something like:
"Must support grouping of 'singleton' instances to facilitate various actions"

We've discussed this in terms of supporting 'dynamic reference resolution'.
There, grouping 'like' instances (eg: Coordinate systems) can be handled by allowing COLLECTION under GLOBALS.

I'm not sure if this solution is satisfactory for other multiple GLOBALS usage.

One point to consider re: allowing COLLECTION under GLOBALS is what does COLLECTION allow?

• MIVOT: allows TABLE_ROW_TEMPLATE and JOIN, and we certainly don't want TEMPLATE under GLOBAL
• MERGED: allows JOIN, which is also TEMPLATE based, so you can't assign IDs to the instances.

It would need be documented that theses were not allowed under the context of GLOBALS, much like the VM syntax restriction that COLUMN is not allowed under GLOBALS.

[lmichel]

For the record:
We already discussed this point in the workshop

[lmichel]

I'm not sure if this solution is satisfactory for other multiple GLOBALS usage.

Neither do I
MIVOT does not allow COLLECTION to be GLOBALS children.
Let's go back to your initial proposal : Dymanic references must resolved against GLOBALS->INSTANCE

[mcdittmar]

MIVOT does not allow COLLECTION to be GLOBALS children.

That is true. I was referring to your suggestion in Issue 6, which would preserve 1 GLOBAL and facilitate that issue as well.

[lmichel]

This can be changed.
I was think on a way to make sure we are looking at a foreign key in something for which the concept of key is relevant .
I've no clear opinion on this case.

[lmichel]

I've a little trouble that can be illustrated by your simple VOTable annotation

I've extracted the code fragment below:

<GLOBALS>
	<INSTANCE dmtype="cube:SparseCube">
		<COMPOSITION dmrole="cube:SparseCube.data">
			<EXTINSTANCES>_cube1_data</EXTINSTANCES>
		</COMPOSITION>
	</INSTANCE>
</GLOBALS>
<TEMPLATES tableref="_cube1">
	<INSTANCE dmtype="cube:NDPoint" ID="_cube1_data">
          ...
          </INSTANCE>
</TEMPLATES>

• The COMPOSITION element with the role cube:SparseCube.data is supposed to be a list of points (model said).
• It refers to the instance _cube1_data

It is not easy for the parser to work this out:

• It has first to resolve the reference _cube1_data

• And then to check whether this instance is within a TEMPLATES

  • If YES it is it must iterate on the table rows
  • If NO it must just create one instance.

  It would be better to say at COMPOSITION level that the data collection must be populated by iterating on table rows.

This issue was solved by my former TABLE_ROW_TEMPLATE, I'm afraid we have now to imagine something to replace it.

[mcdittmar]

EXTINSTANCES becomes JOIN in the merged syntax, and I think you get the simplicity you're looking for there.
Same fragment in merged syntax (current state).
if you write xml after the 3 quotes, you get the syntax coloration (LM)

    <GLOBALS>
      <INSTANCE ID="_TimeSeries" dmtype="cube:SparseCube">
        <ATTRIBUTE dmrole="cube:SparseCube.data">
          <COLLECTION>
            <JOIN tableref="Results" dmref="_cube1_data"/>
          </COLLECTION>
        </ATTRIBUTE>
      </INSTANCE>
    </GLOBALS>
    <TEMPLATES tableref="Results">
      <INSTANCE dmtype="cube:NDPoint" ID="_cube1_data">
	...
      </INSTANCE>
    </TEMPLATES>

[lmichel]

👍

We have to be clear on what to do with TEMPLATES without tableref (for table with ID)
let's work with this and move towards the FILTER and GROUPBY

[mcdittmar]

Do you mean '(for table with no ID)'?
If so, there's not much to do if the TABLE has no ID. If there is only 1, you can keep going, but otherwise there is not much to be done, at least not much to be mandated by the annotation spec.

The MIVOT document suggests using the 'name' as a fallback if the referenced element has no ID, which is fine for other elements, but I don't think that is an option for TABLE.

[lmichel]

I'm ok, I just remind us to mention explicitly the case.

• If one table : no need to have an ID.
• In this case: tableref is empty.
  I prefer this rather than allowing no tableref because it is always safer for parsers to deal with the content of an element than to deal with its presence or absence.

[mcdittmar]

agreed.