#218 Add @svg:points to att.coordinated

[Martin Holmes]

The <zone> element (part of the <facsimile> family) currently defines a rectangle on a <surface> by means of four attributes (@ulx, @uly etc.). There is general agreement among those working with <facsimile> that we need a way to define non-rectangular shapes on surfaces. This proposal is the simplest and most generally-liked option arising out of the recent long discussion on TEI-L and the graphics list.

@svg:points is a "list of points", defined here:

http://www.w3.org/TR/SVG/shapes.html#PointsBNF>

It's not really clear to me by what mechanism an attribute from the svg namespace could be added to a core TEI class when the facsimile module is loaded, though.

[Martin Holmes]

Discussion on the GRAPHICS SIG suggests that adding the attribute in a different namespace is actually not a good idea, for various reasons (compatibility with DTDs, requirement for an extra file for XSD, treading on W3C toes by defining an attribute in the SVG namespace). So the proposal is now:

add @points to att.coordinated, with a content model which is based on SVG @points:

http://www.w3.org/TR/SVG11/shapes.html#PointsBNF

This definition can easily be reduced to a regular expression, and defined as a token in the same way that application/@version is defined:

http://www.tei-c.org/release/doc/tei-p5-doc/en/html/ref-application.html

[example only]
<rng:data type="token">
<rng:param name="pattern">[\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3}</rng:param>
</rng:data>

token { pattern = "[\d]+[a-z]*[\d]*(\.[\d]+[a-z]*[\d]*){0,3}" }
[/example only]

[Martin Holmes]

More discussion suggests the following refinement:

The @points values should all fall within the bounding box of the @ulx, @uly etc.; or, to put it another way, any agent generating or editing @points should simultaneously create @ulx, @uly etc. for the bounding rectangle.

[Dot Porter]

The definition of zone in the Guidelines will need to be tweaked:

Now: <zone> defines a rectangular area contained within a surface element.
Should be: <zone> defines an area contained within a surface element.

[Lou Burnard]

I've marked this green and started modifying the definition of att.coordinated. I need examples, and have the following questions:
- The restriction that the area defined by @points must lie within the bounding box defined by the parent surface is OK, but inconsistent with what we say about rectangular areas (it's perfectly OK to have a zone which extends beyond the borders of the parent surface).
- I need someone who understands this to tell me what the correct pattern for the datatype should be
- making these changes to att.coordinated implies the possibility of defining a nonrectangular *surface* -- is that intentional?
- did we decide whether or not @points was an alternative to (@ulx, urx etc.)?

[Martin Holmes]

This is the pattern for the datatype, as a regexp (according to me -- someone else like Syd should check it):

[\d]+,[\d]+([\s]+[\d]+,[\d]+){2,}

With regard to defining a non-rectangular surface, we are saying that @ulx, @urx and friends are mandatory even when @points is provided, so there will always be a rectangular bounding box that serves as the coordinate space for both <surface> and <zone>. But I think the ability to use @points to define a non-rectangular area within <surface> is actually a nice side-effect of this proposal.

@points is always a supplement, never an alternative to @ulx etc.

[Martin Holmes]

I've just realized that negative values and floating-point values are permitted by the SVG specification. Do we want to follow that model or not? My simple regular expression permits only positive integer values for the coordinates, but it could easily be modified.

[Nobody/Anonymous]

Council agrees that this should be implemented

[Lou Burnard]

Examples still needed; implemented at revision #7432 anyway.

[Martin de la Iglesia]

@points hasn't been added to att.coordinated yet. A new ticket has been created for that purpose: https://sourceforge.net/p/tei/feature-requests/488/