W3C home > Mailing lists > Public > xml-editor@w3.org > January to March 2000

misleading? comments in xml REC text on <

From: David Carlisle <davidc@nag.co.uk>
Date: Fri, 25 Feb 2000 11:31:26 GMT
Message-Id: <200002251131.LAA06062@nag.co.uk>
To: xml-editor@w3.org

  The replacement text may contain both <termref
  def='dt-chardata'>character data</termref> and (except for parameter
  entities) <termref def="dt-markup">markup</termref>, which must be
  recognized in the usual way, except that the replacement text of
  entities used to escape markup delimiters (the entities &magicents;) is
  always treated as data.

This sentence may be interpreted as implying that there is some special
handling for the _particular_ named entities lt, amp etc.

However the intention is (I believe?) that this sentence is not defining
any special processing and that it is just an aside pointing out that
this behaviour is implied by the general processing rules for entity
replacement. In particular an entity reference &mylt; will act in an
identical manner to &lt; (if mylt is defined as lt is defined in section
4.5, and not as at the top of the XML REC xml source:-)

A similar comment applies to

  <wfcnote id='CleanAttrVals'>
  <head>No <code>&lt;</code> in Attribute Values</head>
  <p>The <termref def='dt-repltext'>replacement text</termref> of any entity
  referred to directly or indirectly in an attribute
  value (other than "<code>&amp;lt;</code>") must not contain
  a <code>&lt;</code>.

Whilst the replacement text of lt as defined (but presumably ignored
as not first definition) in the local subset of this file does have a
literal <, the definition given in 4.5 does not, and any similarly
defined entity may be used in an attribute value, there is no
special rule about the entity named `lt' is there? In which case
the parenthetic  (other than "<code>&amp;lt;</code>") is confusing,
or at least it confused me.

Received on Friday, 25 February 2000 06:35:50 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:37:39 UTC