Measurement in HyTime

The measurement module in HyTime provides a way to address objects without having to resort to naming unique identifiers. In order to do this, the module uses a system of coordinate axes, which then allow location of objects by virtue of their coordinate position, whether specified in absolute or relative terms.

In the definition of an axis, a basic unit of counting is established. In HyTime, this is known as the quantum. A quantum is indivisible, therefore obviating the need for floating-point operations when dealing with axis positioning. These quanta may be in a real unit of measurement, or in a virtual unit. When do you use each? That depends on what each axis represents. An axis is a model of positioning, for either space or time. Therefore, an axis may represent a dimension in space (e.g., two axes required to represent a two-dimensional space), or time (as in a video or piece of music). Both types may be combined in a set of axes, such as the representation of how a fly moves around a room in a certain period of time. Such a model would require 4 axes-3 for the three-dimensional space of the room, and one for the temporal measurement. This combination of axes that together can position an object in space/time is called a finite coordinate space, or fcs for short. For those times when real positioning is called for, such as the description of the parts of a machine, real units may be specified. For instances where positions are mostly described in relation to other objects, a virtual unit may be better. For example, in a piece of music, each note is given a virtual unit of time in the score. That is, a quarter note of music is not always a fixed length of time; it varies from situation to situation. It is not made fixed, or real until the moment of performance. Thus, in the abstract, the music time is a virtual time, not a real time. In spatial terms, this is analogous to a slide picture, in which the size of an image on a screen is not determined until the moment of projection. What the slide itself represents is a relative scaling of the various lines to each other. This relation may be maintained in projecting the image, or may be distorted or altered in some way. But this is getting ahead of ourselves-let's stick to measurement!

An object on the axis is specified by naming two positions: the start and end of the object. A pair of marklist in HyTime, is a list of markers or objects that resolve to axis markers. The dimension specification list or dimlist is a list of marker pairs (rather than single markers). This is the structure of each:

	<!--Axis Marker List-->
<!ENTITY % marker --Element type forms allowed in lists-->
	"marklist | dimref | markfun | mrkquery | calspec"> 
< !element marklist
	0 0 (%marker;|#PCDATA)*> 
< !attlist marklist	HyTime	NAME	marklist > 



	< !--Dimension specification list--> 
< !element dimlist	--Nested marklist/dimlist merge into a 
		single list with the effect of
		"((marker1, marker2)|dimspec)*"--
	0 0 (dimlist | dimspec | %marker | #PCDATA)*

< !attlist dimlist HyTime NAME dimlist>

The entity defines a marker as any one of a number of structures, including a function, a query, a reference to another dimension specification, a calendar specification, or another marklist. The dimlist can also be defined in terms of a dimension specification, called a dimspec. This dimspec is of the form (marklist, marklist?), which will resolve to a marker pair.

The data structures outlined above are used in the remaining constructs. An extent is the specification of an event's position and extent on the axes of a schedule. It consists of one or more dimlists, depending on how many axes are needed to schedule an event. The extent is the final piece of what goes into a scheduled extent list, or extlist. Here is its syntax:

	<!--Scheduled Extent List-->
< !element extlist
	0 0
(extlist | extent | dimlist | dimspec | %marker   #PCDATA)>
<!attlist extlist	HyTime	NAME	extlist
			id	ID	#IMPLIED

This allows any necessary level of nesting to eventually derive an extent specification for a scheduled event. The dimspecs are derived from marker pairs, the extents then derived from the dimspecs. The nested lists will therefore resolve to a single list. In order to be able to use this as a resource, so that an extlist may be reusable, there is an attribute known as an extent specification, or exspec, in which a list of id references (IDREFS) points to an already-defined list of extents.

[ Index | Previous Paragraph | Next Paragraph ]