W3C home > Mailing lists > Public > www-tag@w3.org > August 2002

suggested replacement text "circle or spline"

From: Chris Lilley <chris@w3.org>
Date: Fri, 30 Aug 2002 22:13:53 +0200
Message-ID: <170114710843.20020830221353@w3.org>
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
  and which appears unchanged in the current draft

  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

  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

  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.


  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).


  The additional references being



  My remaining dissatisfaction with the suggested replacement text is

  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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:33 UTC