- From: Chris Lilley <chris@w3.org>
- Date: Fri, 30 Aug 2002 22:13:53 +0200
- To: www-tag@w3.org
Hello folks, My attention was recently drawn to discussion during my vacation over the phrase "In the case of a graphics format, the fragment might identify a circle or spline" in the 13 August archdoc http://www.w3.org/2001/tag/2002/0813-archdoc and which appears unchanged in the current draft http://www.w3.org/TR/2002/WD-webarch-20020830/ I believe that the intent of that section as a whole is to look at different fragment identifiers and to give a sense of their variety; also to point out the very different interpretation that RDF places on fragment identifiers. The fragment identifier syntax of HTML is familiar to people on this list; it refers to a single element identified by the NAME attribute on an A element or (in more recent versions) identified by an id attribute of type ID on any element. The general public are also doubtless familiar with the common visual behavior of scrolling the presentation of that document such that the element pointed to is visible, and may consider that the link is to the presentation. The presentational effects of following a link containing a fragment identifier should be clearly separated, in discussions and in specifications, into these two steps - the link into a portion of the resource, and the effect on the presentation (if any) that this produces. I agree that there is a need to show other examples of fragment identifiers on other media types, to convey some of the richer possibilities, before ending that paragraph with the description of what RDF does with fragment identifiers. Paul Prescod has correctly pointed out that fragment identifiers, in XML-based formats, point to elements. So pointing to a circle element, assuming the language has one, is possible. (Pointing to attributes, or portions of element content, is also possible depending on the fragment syntax and I do not believe that Paul intended to exclude that, just to point out that a fragment identifier identifies a portion of the source document). It follows therefore that a fragment identifier in a graphics format does not point to a geometric circle (for example, a circle drawn on the screen as a result of rendering an SVG circle element). It also, from the context, does not point to the mathematical definition of a circle. So, an SVG example would seem warranted. That being the case, I am (nearly) ready to propose alternate text (hooray!) that accomplishes what I believe the objectionable sentence tried to address - to provide a non-HTML example of a fragment identifier. Paul also mentions the need to have fragment identifiers for non-XML formats and I agree that for the purposes of generality, such an example is beneficial (and HTML does not form a suitable non-XML example). Since the original text mentioned graphics formats, a suitable example would be the WebCGM profile of ISO CGM. This has richer linking semantics, for example linking to a particular picture within the metafile, linking to a particular graphical primitive in the content. It also has effects on presentation (panning to display the visual representation of the pointed-to element, highlighting of a pointed-to element, and linking to a predefined view. Since WebCGM predates SVG and since the linking capabilities of SVG were informed by those of WebCGM, the WebCGM example should come first. (Interestingly the linking capabilities of WebCGM were informed by an early draft of XLink, but that is another story). Lastly, since the intent is to give a short example, I believe that references should be provided so the reader can find out further information. OK, suggested replacement text for the entire second paragraph in the Fragment identifiers section. Its now four short paragraphs, one for each example. In the first three, the fact that something in the content is being pointed to is stressed; the secondary effect on the presentation is then noted, in case people thought that linking directly to the presentation was possible. The fourth paragraph is the last sentence of the existing text, lightly edited to clarify what I think it means. I am not an RDF expert and if I got that part wrong, I am sure someone will correct me. <replacement> For instance, if the representation is an HTML 4 document, the fragment identifies an element by its ID. [HTML4frag] The usual effect on a visual presentation of traversing a URI reference containing such a fragment identifier is to scroll the canvas so that the rendering of the identified element comes into view, being placed at the top of the window if possible. If the representation is a WebCGM metafile, the fragment identifier identifies an object in the content by the picture identifier and, within that picture, by the name or object id of that object. It may also pass additional information, such as frame selection, or a command to highlight. [WebCGMfrag] The defined effect on a visual presentation of traversing a URI reference containing such a fragment identifier is to display the selected picture and to pan and possibly zoom the canvas at the so that the rendering of the identified element is completely contained in the current viewport. The rendering of one or more selected objects may also be highlighted. If the representation is an SVG graphic, the fragment identifier either identifies an element in the content by its ID, or identifies the whole document and passes a view specification. [SVGfrag] The defined effect on a visual presentation of traversing a URI reference containing such a fragment identifier is to pan and possibly zoom the canvas at the so that, if an element is identified, the rendering of the identified element is completely contained in the current viewport; if a view specification is given, the specified view is contained in the viewport. In the Resource Description Framework [RDF10frag], fragments do not identify parts of the content but instead can be used to identify the definition of anything, be it abstract (e.g., a dream) or concrete (e.g., an automobile). </replacement> The additional references being [HTML4frag] http://www.w3.org/TR/html4/struct/links.html#h-12.2.3 [WebCGMfrag] http://www.w3.org/TR/REC-WebCGM/REC-03-CGM-IC.html#webcgm_3_1_1 [SVGfrag] http://www.w3.org/TR/SVG/linking.html#LinksIntoSVG My remaining dissatisfaction with the suggested replacement text is that a) it is a bit long (though I could not see a way of making it shorter without reducing the value of the examples of compromising clarity, and it already is a little over simplified). There is some repeated text for precision "The ... effect on a visual presentation of traversing a URI reference containing such a fragment identifier is" maybe a further rewrite would be able to avoid the repetition. b) all of the first three examples reference a complete object/element in the content. An XPath example that identifies an attribute, or an XPointer example that references part of the element content, would better show the variety. Lastly, I observe that the good practice note means that HTML 3.2 and HTML 4 should not be content negotiated, nor HTML and PDF, nor PNG and WebCGM and SVG, etc. Which seems to boild down to 'never content negotiate' or at least 'only content negotiate resources where all the variants have no fragment identifiers'. -- Chris mailto:chris@w3.org
Received on Friday, 30 August 2002 16:14:08 UTC