W3C home > Mailing lists > Public > www-html-editor@w3.org > April to June 1999

Re: Liaison statement on fragment identifiers from Linking WG

From: Bill Smith <bill.smith@sun.com>
Date: Mon, 17 May 1999 06:06:30 -0700
Message-Id: <4.0.1.19990514112509.00e7b6f0@jurassic.eng.sun.com>
To: shane@themacs.com
Cc: Steven Pemberton <Steven.Pemberton@cwi.nl>, w3c-xml-cg@w3.org, w3c-html-wg@w3.org, www-html-editor@w3.org, w3c-xml-linking-wg@w3.org
At 02:50 PM 5/13/99 -0500, Shane P. McCarron wrote:

>At issue here is the working group's (I believe legitimate) concern
>about our responsibility to the existing community of HTML writers and
>their wealth of existing HTML documents. The working group, in its first
>deliverable, is attempting to provide a migration strategy that helps to
>transition those documents from ad hoc, quasi SGML to well formed, valid
>XML. In the long run, fixing these documents and teaching the users how
>to write such documents is good for the entire XML-using community, and
>great for the Internet.

Similarly, those of us active in the XML activity have a responsibility to
keep XML application-neutral. I don't see these as conflicting
responsibilities but rather complementary. My concern is that the XHTML WD,
if moved to recommendation, casues the goals of HTML and XML to come into
conflict, not by design but by accident.

A workable transition strategy for HTML, from an applicatino of SGML, to
generic XML would be to first transition to an application of XML, then to
generic XML (if possible). The step from application-specific, ad hoc,
quasi SGML to generic XML is probably to reasonably contemplate - without
(inadvertently) imposing HTML application-specific semantics onto XML.

>Admittedly, HTML 4.0 has many semantics and commonly used syntactic
>conventions that make it not XML. However, the working group has
>determined that it is relatively easy to develop documents that are XML
>conforming and backward compatible.  This is the scope of XHTML 1.0. You
>may argue about whether such documents will ever be sensibly processed
>as media type text/xml in generic XML user agents.  However, such
>processing was never our goal in this first Recommendation.

But due to HTML's wide-spread use, it is viewed as the language of the web.
Its transition to XML could make XML the future langauge of the web but
simultaneoulsy carrying forward HTML application-specific semantics into
application-neutral XML would be most unfortunate.

I realize the HTML WG does not *intend* this. My fear is that even with the
best intentions, this will in fact occur.

>Perhaps a better solution is one that has different conformance
>requirements on user agents depending upon the document's media type:
>
>If the resource is served as text/html and claims to be an XHTML
>document, examine XML-preferred attributes but permit fallback to
>historical equivalents (id/name, xml:lang/lang)
>
>If the resource is served as text/xml and claims to be an XHTML
>document, only examine XML-preferred attributes.  If necessary, we could
>even accomplish this through a different DTD - although I think that
>might confuse content developers.  Rather, we would set a conformance
>requirement that certain attributes are to be ignored in conforming
>XHTML user agents when processing text/xml streams.

I'd rather see a differnt mime-type altogether rather than rely on the
"claim" that a document is XHTML. I think such a registration and
declartion would send a clear message to developers (and therefor to users)
that XHTML is an application of XML with very specific (HTML-like)
semantics. This seems a better transition strategy to me given the ad hoc
nature of much of the HTML on the web.
Received on Monday, 17 May 1999 09:44:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:16:44 GMT