input@position is saying too much?

[joanma747]

In the following example:

<input name=ymin type=location units=tilematrix rel=image position=top-left axis=row>
<input name=ymax type=location units=tilematrix rel=image position=bottom-left axis=row>
<input name=xmin type=location units=tilematrix rel=image position=top-left axis=column>
<input name=xmax type=location units=tilematrix rel=image position=bottom-right axis=column>

we can see that axis indicates a direction: "row" or "column", "x" or "y", "i" or "j"... Then "position" mentions two directions at the same time what is not necessary. I should expect something like this:

<input name=ymin type=location units=tilematrix rel=image position=top axis=row>
<input name=ymax type=location units=tilematrix rel=image position=bottom axis=row>
<input name=xmin type=location units=tilematrix rel=image position=left axis=column>
<input name=xmax type=location units=tilematrix rel=image position=right axis=column>

This proposal simplifies the current list "input@position" from the current 9 values to 5 values:

• top
• left
• right
• bottom
• center

Note this discussion is independent of the discussion about adding "tile-" or "image-" exposed in issue #24

[prushforth]

<input name=ymin type=location units=tilematrix rel=image position=top axis=column>

That is ambiguous since there are many possible column values. I think we need the position to refer to a point location so that there is no ambiguity.

[joanma747]

The point is defined by 2 inputs and not by a single one:

The top-left corner is defined by:

<input name=ymin type=location units=tilematrix rel=image position=top axis=row>
<input name=xmin type=location units=tilematrix rel=image position=left axis=column>

inputs are 1-dimensional.

[prushforth]

inputs are 1-dimensional.

I can see how this could be confusing. There's no way to compose an object with an input. So my notion here is that the coordinates of the event would be parsed by the input serialization process and the requested axis of the "location" be serialized. I could foresee the concept of providing a template (in an attribute) that could serialize the whole coordinate pair in a custom way (for example reversing the axis order, formatting decimal points ...) but I didn't want to get fancy for no reason at this stage.

So having the input@location serialize some part of the location (a single axis value) seemed like a simple solution.