WD-XSLReq-19980511
[This local archive copy mirrored from the canonical site: http://www.w3.org/TR/1998/WD-XSLReq-19980511.html; links may not have complete integrity, so use the canonical document at this URL if possible.]
WD-XSLReq-19980511
This work is part of the W3C Style Activity. For information about XSL, see http://www.w3.org/Style/XSL.
This is a W3C Working Draft for review by W3C members and other interested parties. It is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C working drafts can be found at http://www.w3.org/TR.
This document gives a list of requirements we consider to be in scope for XSL in general with no reference to timing or target version. This document makes no statement about what specific requirements will be addressed in any particular Working Draft or version of XSL.
In accordance with good language design practice, the full set of requirements are presented so that, at every step in the design process, design choices are made taking the full set of requirements into account, rather than just a subset of those requirements currently being met. It is the XSL WG's expectation that initial drafts/versions of XSL will address only a subset of these requirements.
When reviewing these requirements, keep in mind that XSL is required to perform equally well in batch and interactive environments. These environments run from purely batch formatting at one end of the spectrum, through interactive browser environments, up to structured editors where XSL is used to guide the online presentation of an XML instance while it is being modified.
It must be noted that this list represents a list of requirements which it must be possible to express in XSL. It is not our intent to suggest that every XSL processor must support every feature described here (although processors should handle requirements they cannot satisfy in some more-or-less graceful way).
Within each section, requirements are listed alphabetically, not in any priority order.
Ability to specify absolute/relative positioning of areas on the presentation medium and/or with respect to each other, incuding specification of Z-order for overlapping areas and handling of transparency.
Support for automatic alignment of text from multiple scripts with different alignment rules. Ability to handle sub- and super-scripts.
Support for identifying and including encapsulated, animated objects.
Linking hotspots to items in the flow of text. Another aspect would be manipulating presentation of text within a CGM graphic.
Ability to specify parameters that can be adjusted to make text fit in a specified area.
Support for specification of cropping and scaling of images (and related issues such as bleeds).
Support for/handling of the issues related to cross–references. For example, page numbers and auto-numbering, document wide variables (release, version, etc.), explicit textual cross–references, etc.
Support for headers or footers whose content changes depending on the placement of page breaks (in print media). For example, in an English dictionary, the page header generally contains the first and last words defined on that page.
Support for drop and raised caps.
Ability to change formatting at arbitrary places in the source document.
Support for punctuation that hangs outside the right or left text margin. In English writing, hanging punctuation would place commas and periods at the ends of lines in a paragraph just past the right-most text margin, for example.
Basic running headers and footers (changing on chapter boundaries, page numbers, etc.)
Ability to specify hyphenation information.
Ability to specify presentation characteristics of link ends defined by XLink elements.
Specification of starting and ending indents on the display medium. In English writing, the left margin is the start margin and the right margin is the end margin.
Issues related to indexing: sorting, collating, coalescing. See also cross references. (Easy things should be easy.)
Ability to specify that certain inline markup cannot be broken across lines. Issues: interaction with justification and non-breakable spaces.
Justification/spacing policy controls as per DSSSL.
Support for some/all of the following: ability to enable/disable font kerning metrics, specify font kerning overrides, specify track kerning, automated pair kerning, manual kerning, etc.
Automatic leading and manual control. Relates to ability to address elements below the tag boundary (lead this line more or less tightly).
Support for easy construction of a wide variety of types of lists. (Easy things should be easy)
Side-notes, margin illustrations, etc.
Ability to specify margins. Harmonization of DSSSL/CSS models.
Ability to format text in/around non-rectangular areas.
Support for specification of designs across different aspect ratios, form and media factors using a single stylesheet.
Explicit control over paragraph breaking. (e.g., Suspend and resume a paragraph around an embedded object?)
Ability to specify headers and/or footers that should be fixed at the borders of a scrolling text area. This would provide the functionality most commonly achieved with frames in HTML browsers today.
Page fidelity is neither a requirement nor a goal. Presented with the same document and the same stylesheet, a given renderer should always produce the same results. Different renderers should produce similar results.
Ability to specify square, rounded, and other end-of-rule treatments on rules. Ability to specify the treatment of box corners and border edges.
Flowing text around rectangular areas.
Support for sorting and collating data (for example in index entries, but more generally wherever it is required for proper presentation). Support for other sorts of data-processing functions may be required as well.
XSL will be called upon to process data which is more highly structured, and differently structured, than traditional text documents (for example, calendars, schedules, stock prices, etc.). XSL must provide sufficient functionality to adequately style such documents.
Support for the table models of CSS and DSSSL. Ability to easily format popular source table models such as HTML and CALS.
Support for construction of ToCs and other document views. (Easy things should be easy).
Handle scaling issues.
Background repeat of graphic background.
Ability to specify that columns should be balanced on paged media.
Support for vertical floats, including the ability to control position (top, middle, bottom) and to specify the constraints on how far a float may move from the point of origin.
Support for footnotes in multicolumn text is non-trivial. Ability to specify footnote area, footnote placement, and treatment of very long footnotes.
Support for multiple columns of equal width (with equal width gutters).
Support for multiple columns of unequal width (or gutters of unequal width).
Ability to specify multiple columns where the flow is side-by-side rather than top to bottom. (To align original text and translated text, for example).
Ability to specify vertical keeps (regions or distances within which a page and/or column break may not occur).
Ability to specify handling of widows and orphans.
Capturing a character outline would allow text to flow around the actual shape of a glyph.
Ability to specify and/or select individual glyphs or ligatures, fonts and font substitutions, and font styles.
Support for high-speed font access (construction of fonts on-the-fly, fast substitutions, etc.).
Support for a comprehensive set of font selection and substitution parameters.
Ability to determine character and/or string lengths. Support for text formatting that is contingent on line length (for example, make the first line of a paragraph small caps).
Ability to format text along the path of a bezier (or other type of) curve.
Specification of both absolute and relative units of measurement (pts, picas, inches; ems, ens, exes, etc.)
Allow color to be created/specified in any ICC standardized color space.
Carry the originating color space's ICC profile with the content.
Do not attempt to interject color transforms other than source device to CIE and CIE to target device. Any attempts at color correction/tuning should be done in an authoring (image modification) application in the source color space or by conversion to the authoring (image modification) application's color space. This is because people rarely do simple entire-image transforms, these transforms can be lossy (or introduce rounding errors), and simple transforms can run into gamut limitations.
Do not require all image editing to go through CIE or sRGB if it is not necessary. Again, due to a gamut and transform limitations and rounding issues.
CIE/RGB to CMYK or to Hexachrome, etc. involves non-linear conversions and personal preferences.
At present, in CSS it is not possible to define a color space. There is only one, defined to be sRGB.
When mechanically translating from/to a CSS stylesheet, appropriate translations must be performed.
No colors in an XSL stylesheet may occur in an undefined colorspace.
Ability to specify fills and shading (specification of color and gradients in flood, linear, circular, etc. fills).
Support for masks (e.g., fill all of a specified area except for the area defined by a second parameter or image)..
Support for layers with varying degrees of transparency.
Support for math is expected to come initially from the math operators defined in section 12.6.26 of the DSSSL Standard.
Support for MathML is anticipated.
Internationalization involves issues of character/glyph sets, line-breaking/hyphenation/justification, and layout issues that go well beyond the basic western typography considerations of most applications.
In most languages there is a significant range between the level of formatting/typography needed for business documents and basic markets vs. the level required for advertising and commercial publishing. Web usage produces an interesting blend, as it doesn't require the full typographic capability needed for print advertising, yet requires much of the design and layout capability.
Date and numbering systems seem to vary by country and by language. Digit and value representations are described in unicode. Date handling is not.
Major language groups are listed with no particular order:
This language group includes most North & South American, African business, Latin, and western European languages.
Basic western line-breaking and justification strategy.
The basic controls for justification include the ability to set:
Enable/disable justification using variable word space
Enable/disable letterspacing
Enable/disable kerning
Baseline shift and superior/inferior presets
Paragraph-level leading (line-spacing) control
High-end western justification strategy
The high-end controls for justification extends the basic set to include the ability to set:
Min/opt/max word space
Enable/disable + min/opt/max letterspace
Enable/disable kerning
Select kerning technique and technique-specific controls
Constraints on last line of paragraph:
Do not hyphenate last line in column
Do not hyphenate last word before continuation (jump)
Do not hyphenate last word in paragraph
Min acceptable last line length
Force justify last line if within given distance of full.
Hung punctuation and/or optical margin alignment controls.
Roman (upright) / italic and italic/roman boundary spacing.
Dropped/raised caps (initial string and/or final string)
Baseline shift and superior/inferior presets
Ligature, composite accent, and auto-fraction substitutions
String-level leading control
Control of leading in terms of percent-of-size
Control of leading in terms of extra-lead
Control of leading in terms of baseline-to-baseline-distance
Control on above-baseline leading on first line of column/area
Control on below-baseline leading on last line of column/area
Language-specific ligature substitution
Alternate justification strategies
These line-breaking and justification strategies have controls in addition to or other than those listed above.
Head fit
May override above controls with a wider adjustment range. In addition may allow character squeeze/stretch (setwidth adjustment or anamorphic scale)
Vertical headlining
Vertically set labels and headlines (Top-to-bottom character progression, left-to-right line progression)
Balanced line
This strategy is used for headlines and for labels in shapes (such as flowchart symbols).
Weighted/preferred break strategies
Used for topic headings in Yellow Pages and similar documents.
Special strategies for TOC
Some TOCs have highly-tuned and unique line breaking and balancing rules the do not fit into any of the above models.
Hyphenation issues
Ability to enable and disable hyphenation
Ability to support multiple languages (rule or dictionary package). Other controls related to each hyphenation package:
Min chars before first hyphen
Min chars after last hyphen
Min word to hyphenate.
Ability to support multiple override dictionaries (by language). Search order (precedence) among override dictionaries, by language.
Ability to control precedence of hyphenation
Hyphenate on hard hyphen
Hyphenate on user-entered soft-hyphen
Hyphenate on dictionary/rule package hyphen, for each dictionary/rule package, honor:
Only preferred hyphens
Secondary hyphens
Any hyphens
Honor dictionary/rule hyphens in words with hard hyphen
Honor dictionary/rule hyphens in word with soft hyphen
Honor hard hyphens in word with soft hyphen
Disable rule hyphen if word is found in dictionary.
Northern European languages (German, Dutch, Swedish, Norwegian, Danish, etc.) respell words when breaks/hyphens are inserted.
Language dependent ligature splitting when necessary for hyphenation.
Date and time formats
Month names vary by country
DD/MM/YY (Europe), MM/DD/YY (US)
12-hour vs. 24-hour clock
Daylight savings time usage varies
Numbering Systems (No known special issues here)
JIS-4051 (1996) line-breaking and justification strategy This justification strategy has different controls from those of western text, though the western controls may be used for proportional western within predominantly Japanese documents.
Justification properties:
Use full-width vs. half-width Kana
Use full-width, half-width, or proportional western
Enable/disable Tsume (proportional Kanji & Kana)
Use conditional half-width punctuation to provide justification
Settings for min/opt/max J-J Spacing
This is the value used for the 1/2 and 1/4 spaces inserted under the JIS-4051 rules for specified pairs of Japanese character classes. (0/0/0 disables this feature, min=opt=max allows the space but does not adjust it for justification, min<opt<max allows this spacing to contribute to justification)
Settings for min/opt/max J-/W-boundary Spacing
This is the value used for the spaces inserted under the JIS-4051 rules for boundaries where there is a Japanese-to-western or western-to-Japanese language transition..
Settings for min/opt/max Japanese Letterspacing
All western-language controls from above are provided for western text in Japanese documents, however the settings/values may be different than they would be in western-language documents.
Baseline/centerline adjustment when mixing western and Japanese text on same line.
Composition features that are unique to Asian languages
Character/glyph substitutions for different versions of JIS-____
Vertical text (Top-to-Bottom character progression, with Right-to-Left line progression)
Baseline/centerline adjustment when mixing western and Japanese text on same line.
Glyph and baseline rotation for western text in Japanese vertical text
Glyph substitution of vertical form glyph (parens and punct have H & V forms).
Rubi (glyph annotation)
Controls on Rubi: [TBD]
Warichu (multi-line comment, inline)
Controls on Warichu: [TBD]
Furiwaki (inline list)
Controls on Furiwaki: [TBD]
Kumisuji (cross-line text)
Controls on Kumisuji: [TBD]
Kendot (emphasizing marks)
Controls on Kendot: [TBD]
Justified tab fields
Borders and background highlights
(Since italic and bold are not commonly used in Japanese and other Asian languages, due to the complexity of the characters; color, borders, and backgrounds are used more frequently than in other languages)
Date and time formats
All issues of western dates
Imperial dates (measured from the day an emporer is enthroned)
Start of year is not Jan 1.
Numbering Systems - Non-western numbering and western numbering
Japanese measuring systems for type and layout
Toyo named spot color systems
The requirements of these languages are subsets of the requirements of Japanese, though they have different character sets.
Korean adds some unique character-compositiing requirements.
One Asian language supports a paired-vertical-column format. The reading order is:
| 10 | 09 | 02 | 01 | <-- start | |
| 12 | 11 | 04 | 03 | ||
| 14 | 13 | 06 | 05 | ||
| end --> | 16 | 15 | 08 | 07 |
Date and time formats - Imperial dates differ by country
Numbering Systems - Non-western numbering and western numbering
This is a script language that is unique in a number of ways:
Mixed writing direction
The letter progression is mostly right-to-left with intermingled left-to-right numbers. Line progression is top-to-bottom.
Calligraphic/script language
This script (connected letter) language is one that extends calligraphy to an art form. Arabic-language newspapers (even those outside the middle east) may have a calligrapher on staff to produce the headlines.
Prefix, infix, suffix, and stand-alone glyph variants
Most letters have at least 4 forms, based on their placement within the word. Other contextual substitutions (first/last of story, first/last of paragraph, or first/last of sentence forms) are also prevalent.
No hyphenation
This is one of the few languages that doesn't use hyphenation or break words in the middle.
Justification methods
Justification is accomplished through the stretching of letters (in lower-quality forms, through the insertion of stretcher bars [kashidas]).
Compound accents with accent relocation
This language has multi-level accents and vowel marks. When marks are combined on a single letter, there are complex precedence rules that govern the placement and changes in placement of these marks.
Date and time formats
Numbering Systems - Numbers set left-to-right.
Page order
Right-to-left reading languages often reverse the page order in a book >From that of left-to-right reading languages.
Though stylistically simpler than Arabic, Hebrew carries many similar characteristics (Mixed writing directions, glyph variants, etc.). If you satisfy the requirements for western Europe and Arabic, you have satisfied most of those of Hebrew.
Date and time formats
Numbering Systems
Special treatment of 15 & 16
Arabic/European numbers set left-to-right.
Page order
Right-to-left reading languages often reverse the page order in a book >From that of left-to-right reading languages.
Except for character sets, there are no known requirements for these languages that are not covered by those of western Europe. We need to confirm this.
Many of these are script-based languages, many of the requirements of Arabic will apply
Prefix, infix, suffix, and stand-alone glyph variants
No hyphenation (?)
Justification is accomplished through the stretching of letters.
Accent relocation and/or resequencing
Accent leaders
Accents are relocated before and/or after the word and connected to the associated letter/syllable with an ornate 'L' or reverse-'L' leader line.
Vowel relocation and/or resequencing
Differing baseline/centerline, and top-align strategies when mixing languages or writing directions.
Date and time formats
Numbering Systems
There are a number of unique numbering systems in this area.
Unknown.
Includes non-iconic form of Vietnamese
Thai has many typographic characteristics from Indic-rim.
One Asian language supports a paired-vertical-column format.
Differing baseline/centerline, and top-align strategies when mixing languages or writing directions.
Date and time formats
Numbering Systems
There are a number of issues regarding infrequently used, dead, and archaic languages that we might want to support for academic studies and literature:
Character sets
Unicode does not include support for all these languages.
Unique layout, line breaking and justification strategies:
Alternating left-to-right and right-to-left lines
Snaking lines (alternating and inverting)
There is one bottom-to-top reading language?
Ancestors, children, siblings, attributes, content, disjunctions, negation, enumerations, computed select based upon arbitrary query expressions.
Arithmetic, simple boolean comparisons, boolean logic, substrings, string concatenation.
Scalar types, units of measure, Flow Objects, XML Objects
No global side effects.
The expression language should have a set of procedures that are builtin to the XSL language. These are still to be identified.
Content-side scripting. This is scripting that generates content (on the server, for example) to be sent to the client for rendering. Viewed as out-of-scope.
Process-side scripting (scripting in the construction of the result).
Renderer-side scripting (scripting in the rendered result). Viewed as out-of-scope.
“Browser”-side scripting (other scripting in the browser). Viewed as out-of-scope.
For reuse. Parameterized, but not recursive.
Support for defining the interactive response to certain behavioral and user-interface events such as mouse-clicks and loading and unloading of a document.
Support for defining “input elements” of a document (e.g. HTML forms).
Support for defining the interactive response of all visible objects. Support for renderer-meaningful mechanisms and language for defining the action that occurs upon interaction.
Support for defining the look and feel of the input objects (i.e., mechanisms to bind the abstract input elements to concrete presentational widgets).
Support for audio (aural) stylesheets.
Additional accessibility support will be defined.
Possibly provide the ability to specify additional Flow Objects or XML Objects
Possibly provide the ability to specify additional characteristics on objects.
Ability to specify the stylesheet(s) that apply to a particular document (or class of documents)
Specify how author/reader stylesheets can cascade.
Allow stylesheets to be composed (possibly dynamically) from multiple individual stylesheet fragments.
Specify the selection of criteria for determining what stylesheet (or what part of a stylesheet) overrides another. Handling of specificity issues.
Ability to specify formatting of areas outside the typical display area.
Ability to specify stock and grain direction for print media.
Ability to specify the order and nature of imposition (the process of constructing signatures from pages) with the focus on the types of imposition supported by standard laser printers.
Ability to specify job control for specific devices.