Details

    • Type: Bug Bug
    • Status: Applied
    • Priority: Blocker Blocker
    • Resolution: Fixed
    • Affects Version/s: ODF 1.2 CD 05
    • Fix Version/s: ODF 1.2 CD 06
    • Component/s: Graphics
    • Labels:
      None
    • Resolution:
      Change 18.3.9 to "A coordinate represents a length in a coordinate system. It specifies the distance from the origin of the coordinate system along the relevant axis. "

      Description

      18.3.9 has been changed from "Like a length, except that the physical length denotes a certain point." to "A tuple of numeric values that defines a position."

      I don't think it makes sense to have a coordinate to be "a tuple". Shouldn't it just be a "A numeric value that describes a position"?

        Activity

        Andreas Guelzow created issue -
        Hide
        Michael Brauer added a comment -
        The changed definition is indeed wrong. But a coordinate is also not just a numeric value. It contains a unit. So, if we don't want to revert to the original text, we may say:

        A length that describes a position

        or

        A numeric value and unit that describe a position
        Show
        Michael Brauer added a comment - The changed definition is indeed wrong. But a coordinate is also not just a numeric value. It contains a unit. So, if we don't want to revert to the original text, we may say: A length that describes a position or A numeric value and unit that describe a position
        Michael Brauer made changes -
        Field Original Value New Value
        Status New [ 10000 ] Open [ 1 ]
        Resolution Change 18.3.9 to "A length that describes a position."
        Assignee Patrick Durusau [ patrick ]
        Priority Major [ 3 ] Blocker [ 1 ]
        Michael Brauer made changes -
        Status Open [ 1 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Hide
        Bart Hanssens added a comment -
        Origin of this change: OFFICE-3289
        Show
        Bart Hanssens added a comment - Origin of this change: OFFICE-3289
        Hide
        Patrick Durusau added a comment -
        Well, a tuple can have a single value, in which case it is called a singleton. So a tuple would cover both a single value as well as multiple values, such as for geographic coordinates or even 3 (or higher) dimension coordinates.

        That isn't captured other than vaguely by "numeric value."

        BTW, "numeric value" does not specify a type of numeric value.

        (Neither did my suggestion of tuple but I was trying to say no more than the current text.)

        Two questions:

        1) Should we use tuple?

        2) If yes or no, what about the "type" of the value?
        Show
        Patrick Durusau added a comment - Well, a tuple can have a single value, in which case it is called a singleton. So a tuple would cover both a single value as well as multiple values, such as for geographic coordinates or even 3 (or higher) dimension coordinates. That isn't captured other than vaguely by "numeric value." BTW, "numeric value" does not specify a type of numeric value. (Neither did my suggestion of tuple but I was trying to say no more than the current text.) Two questions: 1) Should we use tuple? 2) If yes or no, what about the "type" of the value?
        Hide
        Andreas Guelzow added a comment -
        If we say "A length that describes a position." why do we need to have this data type at all? We should just be using length. The data type need not (should not?) include a statement about what the data is used for.

        @Patrick: do we ever use this to specify a pair or triple etc.? If we do then we need to specify how the components are separated: by whitespace, semicolon?
        Show
        Andreas Guelzow added a comment - If we say "A length that describes a position." why do we need to have this data type at all? We should just be using length. The data type need not (should not?) include a statement about what the data is used for. @Patrick: do we ever use this to specify a pair or triple etc.? If we do then we need to specify how the components are separated: by whitespace, semicolon?
        Andreas Guelzow made changes -
        Summary 18.3.9 coordinate should not be a tuple NEEDS-DISCUSSION 18.3.9 coordinate should not be a tuple
        Description 18.3.9 has been changed from "Like a length, except that the physical length denotes a certain point." to "A tuple of numeric values that defines a position."

        I don't think it makes sense to have a coordinate to be "a tuple". Shouldn't it just be a "A numeric value that describes a position"?
        18.3.9 has been changed from "Like a length, except that the physical length denotes a certain point." to "A tuple of numeric values that defines a position."

        I don't think it makes sense to have a coordinate to be "a tuple". Shouldn't it just be a "A numeric value that describes a position"?
        Hide
        Patrick Durusau added a comment -
        Andreas,

        Don't know the answer to the question of usage. Seems like length would be good enough if it were a simple string.

        Good question on separation. I know in some cases we have specified that separator in this version.
        Show
        Patrick Durusau added a comment - Andreas, Don't know the answer to the question of usage. Seems like length would be good enough if it were a simple string. Good question on separation. I know in some cases we have specified that separator in this version.
        Robert Weir made changes -
        Summary NEEDS-DISCUSSION 18.3.9 coordinate should not be a tuple 18.3.9 coordinate should not be a tuple
        Component/s Needs Discussion [ 10165 ]
        Hide
        Michael Brauer added a comment -
        From the pure validation perspective we could use a length. But the datatypes also carry some amount of semantic information. Take for instance the ID and NCName datatypes. They both are lexically the same, but they anyway carry different semantics.

        Anyway. There is nothing wrong with having two datatypes that have the same lexical representation. Even if one is not required, this seems not be a change that we must or should make in the last minute, and after a public review. In particular if ODF 1.0 and 1.1 had teh same differentiation, and no one cared.

        Show
        Michael Brauer added a comment - From the pure validation perspective we could use a length. But the datatypes also carry some amount of semantic information. Take for instance the ID and NCName datatypes. They both are lexically the same, but they anyway carry different semantics. Anyway. There is nothing wrong with having two datatypes that have the same lexical representation. Even if one is not required, this seems not be a change that we must or should make in the last minute, and after a public review. In particular if ODF 1.0 and 1.1 had teh same differentiation, and no one cared.
        Hide
        Michael Brauer added a comment -
        Andreas: I suggest we remove the NEEDS DISCUSSION. There are more serious issues to discuss.
        Show
        Michael Brauer added a comment - Andreas: I suggest we remove the NEEDS DISCUSSION. There are more serious issues to discuss.
        Hide
        Andreas Guelzow added a comment -
        From an implementors point of view there is really nothing more serious to discuss than this. The current draft defines a coordinate as just a numeric value, whether you call this a tuple or not is of less importance.

        The proposed resolution now is to change this into a length (which is not just a numerical value but must carry a unit).

        This is a huge and significant change.

        I do realize that in ODF 1.0 we have:
        <define name="coordinate">
        <ref name="length"/>
        </define>
        with
        <define name="length">
        <data type="string">
        <param name="pattern">-?([0-9]+(\.[0-9]*)?|\.[0-9]+)((cm)|(mm)|(in)|
        (pt)|(pc)|(px))</param>
        </data>
        </define>

        So the proposed resolution is to return to the definition of ODF 1.0. While this may be the right decision we really should not change our data types quite that easily.
        Show
        Andreas Guelzow added a comment - From an implementors point of view there is really nothing more serious to discuss than this. The current draft defines a coordinate as just a numeric value, whether you call this a tuple or not is of less importance. The proposed resolution now is to change this into a length (which is not just a numerical value but must carry a unit). This is a huge and significant change. I do realize that in ODF 1.0 we have: <define name="coordinate"> <ref name="length"/> </define> with <define name="length"> <data type="string"> <param name="pattern">-?([0-9]+(\.[0-9]*)?|\.[0-9]+)((cm)|(mm)|(in)| (pt)|(pc)|(px))</param> </data> </define> So the proposed resolution is to return to the definition of ODF 1.0. While this may be the right decision we really should not change our data types quite that easily.
        Hide
        Andreas Guelzow added a comment -
        Moreover, a length by itself can never describe a position but just a distance. To describe a position we would also need to have a direction and an origin from which we measured the distance to obtain our position. So the proposed resolution cannot be correct.
        Show
        Andreas Guelzow added a comment - Moreover, a length by itself can never describe a position but just a distance. To describe a position we would also need to have a direction and an origin from which we measured the distance to obtain our position. So the proposed resolution cannot be correct.
        Hide
        Andreas Guelzow added a comment -
        Another consideration should be that we often use coordinate as the type of svg:... attributes whose definition is referred to [SVG]. In [SVG] coordinates have no units, ie. they are not length. For example "svg:x" has type coordinate and the description is "See §5.1.2 of [SVG]" with some added note about non-rectangular objects. In [SVG] the atribute "x" is a coordinate, not a length. So its definition cannot apply to svg:x if that is in fact a length.
        Show
        Andreas Guelzow added a comment - Another consideration should be that we often use coordinate as the type of svg:... attributes whose definition is referred to [SVG]. In [SVG] coordinates have no units, ie. they are not length. For example "svg:x" has type coordinate and the description is "See §5.1.2 of [SVG]" with some added note about non-rectangular objects. In [SVG] the atribute "x" is a coordinate, not a length. So its definition cannot apply to svg:x if that is in fact a length.
        Hide
        Michael Brauer added a comment -
        Andreas: In SVG, the attribute x may have a unit. See

        ttp://www.w3.org/TR/SVG11/shapes.html#RectElement

        which says:

        x = "<coordinate>"

        Coordinate is defined here

        http://www.w3.org/TR/SVG11/types.html#DataTypeCoordinate

        and refers back to length:

        http://www.w3.org/TR/SVG11/types.html#Length

        which says:

        length ::= number ("em" | "ex" | "px" | "in" | "cm" | "mm" | "pt" | "pc" | "%")?

        So, it is not only the case that the x attribute has an (optional) unit, but further our use of the term "coordinate" is in alignment with SVG.
        Show
        Michael Brauer added a comment - Andreas: In SVG, the attribute x may have a unit. See ttp://www.w3.org/TR/SVG11/shapes.html#RectElement which says: x = "<coordinate>" Coordinate is defined here http://www.w3.org/TR/SVG11/types.html#DataTypeCoordinate and refers back to length: http://www.w3.org/TR/SVG11/types.html#Length which says: length ::= number ("em" | "ex" | "px" | "in" | "cm" | "mm" | "pt" | "pc" | "%")? So, it is not only the case that the x attribute has an (optional) unit, but further our use of the term "coordinate" is in alignment with SVG.
        Hide
        Andreas Guelzow added a comment -
        Yes indeed my comment re SVG is false.
        Show
        Andreas Guelzow added a comment - Yes indeed my comment re SVG is false.
        Hide
        Andreas Guelzow added a comment -
        But note that SVG doesn't just say that it is a length but specifically considers it the distance from the origin. of the user coordinate system. If we had something like that I wouldn't have a problem. But just saying length without specifying from where and in which direction is insufficient.
        Show
        Andreas Guelzow added a comment - But note that SVG doesn't just say that it is a length but specifically considers it the distance from the origin. of the user coordinate system. If we had something like that I wouldn't have a problem. But just saying length without specifying from where and in which direction is insufficient.
        Hide
        Michael Brauer added a comment -
        Okay. I see the issue. In that case, I suggest we says something similar as SVG:

        A coordinate represents a length in a coordinate system. It specifies the distance from the origin of the coordinate system along the relevant axis.

        Regarding your comment from the 24th: "So the proposed resolution is to return to the definition of ODF 1.0. While this may be the right decision we really should not change our data types quite that easily." I think it is clear that the change in the datatype was an error and not intended.

        I believe with that revised definition of "coordinate" this issue is resolved. I will keep the "needs-discussion" flag for another week. If no objections are raised by when, I will remove it.


        Show
        Michael Brauer added a comment - Okay. I see the issue. In that case, I suggest we says something similar as SVG: A coordinate represents a length in a coordinate system. It specifies the distance from the origin of the coordinate system along the relevant axis. Regarding your comment from the 24th: "So the proposed resolution is to return to the definition of ODF 1.0. While this may be the right decision we really should not change our data types quite that easily." I think it is clear that the change in the datatype was an error and not intended. I believe with that revised definition of "coordinate" this issue is resolved. I will keep the "needs-discussion" flag for another week. If no objections are raised by when, I will remove it.
        Hide
        Andreas Guelzow added a comment -
        I don't know what the current "resolution" is:

        Change 18.3.9 to "A length that describes a position." -- in this case my concerns expressed in earlier comments still apply.

        Change 18.3.9 to "A coordinate represents a length in a coordinate system. It specifies the distance from the origin of the coordinate system along the relevant axis." -- I would find this an acceptable solution, but it really only changes the issue at hand: we have to make sure we know which coordinate system is used for every use case of coordinate.
        Show
        Andreas Guelzow added a comment - I don't know what the current "resolution" is: Change 18.3.9 to "A length that describes a position." -- in this case my concerns expressed in earlier comments still apply. Change 18.3.9 to "A coordinate represents a length in a coordinate system. It specifies the distance from the origin of the coordinate system along the relevant axis." -- I would find this an acceptable solution, but it really only changes the issue at hand: we have to make sure we know which coordinate system is used for every use case of coordinate.
        Hide
        Dennis Hamilton added a comment -
        I share the concern that Andreas has about this.

        The most direct statement is the second part of Michael's suggestion: "The coordinate value specifies the distance from the origin of the coordinate system along the relevant axis."

        For this to work, we need to know the origin and the orientation of the coordinate system. We may also need to know its units in physical measures, if that is actually permitted for a given case. (Speaking generally, it might not be for a coordinate system that lives in an embedded frame and has a transform-defined relationship to its parent system.)

        Note that the SVG grammar might not prevent signed numbers (?) and the "%" option allows frame-relative coordinates. It is also not necessary to specify fixed-size units (so presumably the framing coordinate system is applicable) and it is not clear when physical units are applicable, depending on the prevaling coordinate system (which might only be grounded on fixed units as part of a transform relative to an enclosing coordinate system).

        So not all of the lexically-approved forms may provide nominally-meaningful values in individual cases, and that is a factor that is only resolveable by having more precise information about the prevaling coordinate system and the nature of its unit measures, orientation, and constraining frame in every case.

        Regardless, I agree that these should not be called lenghts, they are (relative) distances of a point projected onto its respective axes. If there was a line from the origin to the coordinate-defined position, that line would have a length but is unlikely to be the same as one of the coordinate values (unless all of the other coordinates are 0).
        Show
        Dennis Hamilton added a comment - I share the concern that Andreas has about this. The most direct statement is the second part of Michael's suggestion: "The coordinate value specifies the distance from the origin of the coordinate system along the relevant axis." For this to work, we need to know the origin and the orientation of the coordinate system. We may also need to know its units in physical measures, if that is actually permitted for a given case. (Speaking generally, it might not be for a coordinate system that lives in an embedded frame and has a transform-defined relationship to its parent system.) Note that the SVG grammar might not prevent signed numbers (?) and the "%" option allows frame-relative coordinates. It is also not necessary to specify fixed-size units (so presumably the framing coordinate system is applicable) and it is not clear when physical units are applicable, depending on the prevaling coordinate system (which might only be grounded on fixed units as part of a transform relative to an enclosing coordinate system). So not all of the lexically-approved forms may provide nominally-meaningful values in individual cases, and that is a factor that is only resolveable by having more precise information about the prevaling coordinate system and the nature of its unit measures, orientation, and constraining frame in every case. Regardless, I agree that these should not be called lenghts, they are (relative) distances of a point projected onto its respective axes. If there was a line from the origin to the coordinate-defined position, that line would have a length but is unlikely to be the same as one of the coordinate values (unless all of the other coordinates are 0).
        Hide
        Andreas Guelzow added a comment -
        The schema currently describes the coordinates as lengths (positive, negative or 0). These lengths always carry a unit.

        So units of the coordinate sytem really don't matter. What we need to know is the origin, the direction of the positive x-axis, the direction of the positive y-axis. If we use the top left corner of a surrounding element, we surely want a left-handed coordinate sysem with a horizontal (left-to-right) x-axis, and a vertical (top to bottom) y-axis.
        Show
        Andreas Guelzow added a comment - The schema currently describes the coordinates as lengths (positive, negative or 0). These lengths always carry a unit. So units of the coordinate sytem really don't matter. What we need to know is the origin, the direction of the positive x-axis, the direction of the positive y-axis. If we use the top left corner of a surrounding element, we surely want a left-handed coordinate sysem with a horizontal (left-to-right) x-axis, and a vertical (top to bottom) y-axis.
        Hide
        Michael Brauer added a comment -
        Andreas: I did forget to update the resolution. It is "
        A coordinate represents a length in a coordinate system. It specifies the distance from the origin of the coordinate system along the relevant axis. " This may only resolve the issue at hands, but, well, we anyway should not use one issues to discuss or resolve additional issues that may exist.

        I think this issue is resolved now. If no objections are raised to this issue, I will remove the needs-discussion flag in a week.
        Show
        Michael Brauer added a comment - Andreas: I did forget to update the resolution. It is " A coordinate represents a length in a coordinate system. It specifies the distance from the origin of the coordinate system along the relevant axis. " This may only resolve the issue at hands, but, well, we anyway should not use one issues to discuss or resolve additional issues that may exist. I think this issue is resolved now. If no objections are raised to this issue, I will remove the needs-discussion flag in a week.
        Hide
        Robert Weir added a comment -
        No objections on 10/11 TC call
        Show
        Robert Weir added a comment - No objections on 10/11 TC call
        Robert Weir made changes -
        Component/s Needs Discussion [ 10165 ]
        Hide
        Andreas Guelzow added a comment -
        copied the resolution into the resolution field
        Show
        Andreas Guelzow added a comment - copied the resolution into the resolution field
        Andreas Guelzow made changes -
        Resolution Change 18.3.9 to "A length that describes a position." Change 18.3.9 to "A coordinate represents a length in a coordinate system. It specifies the distance from the origin of the coordinate system along the relevant axis. "
        Hide
        Patrick Durusau added a comment -
        Applied text will appear in OpenDocument-v1.2-cd05-part1-editor-revision_03
        Show
        Patrick Durusau added a comment - Applied text will appear in OpenDocument-v1.2-cd05-part1-editor-revision_03
        Patrick Durusau made changes -
        Status Resolved [ 5 ] Applied [ 10002 ]

          People

          • Assignee:
            Patrick Durusau
            Reporter:
            Andreas Guelzow
          • Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: