Re: Liaison statement on fragment identifiers from Linking WG

At 8:56 AM -0400 6/2/99, Steven Pemberton wrote:
>Dear XML Linking group,
>
>There doesn't seem to have been a response to my reply from a week
>ago, so I am resending it.
>
>This issue is the last one holding up the final release of XHTML, so
>we would like to resolve it as soon as possible.
>
>By the way, in my original message there was a typo on my behalf: I
>said "NAME is of type NAME", where I meant that is is of type Name
>Token, but I guess you realised that.

The following is the reply that we drafted. It seems not to have been
forwarded beyond the XML-linking WG, due to our error. An advantage of this
mistake has been that the note has been available for review for almost a
week, and has generated some discussion, but no objections.

  -- David Durand

Response follows:

This note represents the XML-Linking WG's formal response to the current
last call for comments on XHTML.

The current documents that represent last call for XHTML show internal
inconsistencies between the DTD and the prose specification. For example,
the type of the NAME attribute on the anchor element. As a consequence, it
is impossible to accept the draft submitted for last call as-is, and we
believe there must be a subsequent last call.

There has been considerable dialog on fragment identifiers and their
meaning in XPointer/XML and XHTML. The Linking WG sent a liaison documentto
the HTML WG suggesting a solution to the "bare name
token" problem.(http://www.textuality.com/xml/naked.html Answered by Steve
Pemberton at
http://lists.w3.org/Archives/Member/w3c-html-wg/1999AprJun/0298.html) The
HTML WG rejected that proposal, and through Steven
Pemberton has proposed an alternative). Unfortunately,
this proposal cannot be implemented with syntactically correct XML. In
particular, XML has no "NAME" attribute type. XML does provide NMTOKEN, but
the set of legal values for such attributes does not match that for id
(even ignoring the uniqueness restriction of the latter).

We are generally concerned at the pace of this effort, given the
inconsistencies in the documents we are being asked to evaluate and
approve. A final W3C Recommendation produced from initially inconsistent
documents, by addition of changes not formally reviewed by the membership
in another last call, seems to us highly inadvisable; particularly so for a
Recommendation so likely to be as important as XHTML. In addition, we are
unaware of any implementation experience with XHTML that would increase our
confidence in the workability of the proposed solutions to the bare name
token issue.

For this reason we recommend that the HTML WG postpone moving to Proposed
Recommendation, issue a corrected and consistent draft, and resubmit for
another last call. We also suggest that reports of implementation
experience should be gathered. This will enable a meaningful review and
evaluation.

It is still our belief that none of the HTML WG solutions proposed fit our
requirements.
Requiring duplicate values on the name and id attributes would in a perfect
world enable a generic XML processor to discover and use the ids. However,
such a processor could not validate the requirement for the values to be
identical. In addition, it is likely that in practice applications would
"fall back" to using the name attribute when the values are unequal,
leading to interoperability problems with conforming XML implementations.

Worse, a highly likely error will exacerbate this problem. People will
likely not insert the extra values, not ensure they are identical, or not
insert them uniformly for all element types. In particular, this strategy
would not allow the detection of an illegal conversion "strategy" that
would simply change the syntax of the empty tags to agree with the XML
syntax and leave the other markup, including the name attributes, unchanged.

These problems may be best avoided by considering XHTML a separate MIME
type. By doing so, the HTML WG ca n effect a transition from HTML 4.0
syntax and semantics to XML syntax, and HTML semantics. At a later date it
might be possible to complete the transtion to generic XML semantics. The
current proposal to use the XML mime type for XHTML confuses the
distinction between application-independent XML semantics and HTML-specific
semantics. This will make both validation and user education significantly
more difficult. It also creates a strong incentive for browser implementors
to violate the standard to make incorrect documents process successfully.

BIll Smith, Steve DeRose, David Durand
_________________________________________
David Durand              dgd@cs.bu.edu  \  david@dynamicDiagrams.com
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://www.dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Received on Wednesday, 2 June 1999 10:15:21 UTC