W3C home > Mailing lists > Public > public-html@w3.org > February 2009

Re: What's the problem? "Reuse of 1998 XHTML namespace is potentially misleading/wrong"

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 16 Feb 2009 13:55:18 -0800
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, HTML WG <public-html@w3.org>
Message-id: <DC066479-DB1F-4A9F-8479-F031216414B9@apple.com>
To: Larry Masinter <masinter@adobe.com>

On Feb 16, 2009, at 11:47 AM, Larry Masinter wrote:

> I thought we could close the namespace action, based on a  
> misunderstanding. The namespace action can be closed iff there is  
> some other mechanism for distinguishing between XHTML5 and XHTML2  
> content.
>
> In any case, the DOCTYPE versioning issue is still open. I am  
> sympathetic to the arguments that "DOCTYPE" isn't a particularly  
> effective solution to the versioning problem.
>
> I don't accept the "let's just hope XHTML2 goes away" as a  
> reasonable resolution of the versioning issue, because it doesn't  
> account for the ever so slight possibility that -- heaven forbid --  
> there might be anything in (X)HTML5 that one might actually ever  
> want to change? So that deployed user agents might actually know  
> when they are being presented with incompatible content?

I think you are needlessly tying ISSUE-60 and ISSUE-4 here. ISSUE-60  
requests a change of the XML namespace used by HTML5, to avoid  
conflict with XHTML2. Since you are backing off your original proposal  
to close this issue without further action, here's my own  
justification for doing so:

When the HTML and XHTML2 working groups were chartered, and at the  
time WHATWG's Web Apps 1.0 was adopted as our initial draft, HTML5  
used the classic XHTML1 XML namespace URI, while XHTML2 used a  
different namespace URI. The HTML5 use of the 1999 XHTML URI was  
driven by the Design Principles, most notably the Degrade Gracefully  
principle. We'd like future XHTML5 content to work to the extent  
possible in existing XHTML UAs, and that would not be possible if it  
used a different namespace URI. Since then, the XHTML2 WG has decided  
to change XHTML2 to use the XHTML1 namespace URI. Because XHTML2  
changes the meaning and behavior of various XHTML elements in an  
incompatible way, this creates a conflict.

However, since the conflict was created by an XHTML2 change, I do not  
think we have an obligation to make a unilateral change to avoid it.  
Furthermore, we have a clearly stated technical justification for our  
use of the XHTML1 namespace based on our Design Principles. If the  
XHTML2 WG would like us to change, they should provide a technical  
justification.

In conclusion, I think we should affirm our use of the XHTML1  
namespace and politely decline the XHTML2 WG's request to change our  
namespace URI.


ISSUE-4 is about versioning. I don't think anyone seriously proposes  
that changing the namespace URI would be an appropriate solution to  
the versioning issue. (If you do mean to propose this, then I'd be  
glad to discuss the technical pros and cons in a separate thread). I  
think most Working Group members would support our continued use of  
the XHTML1 namespace URI, whether or not they prefer to have a  
versioning mechanism.

Regards,
Maciej



>
>
> Larry
> --
> http://larry.masinter.net
>
>
> -----Original Message-----
> From: Maciej Stachowiak [mailto:mjs@apple.com]
> Sent: Monday, February 16, 2009 11:24 AM
> To: Larry Masinter
> Cc: Lachlan Hunt; HTML WG
> Subject: Re: What's the problem? "Reuse of 1998 XHTML namespace is  
> potentially misleading/wrong"
>
>
> On Feb 16, 2009, at 11:10 AM, Larry Masinter wrote:
>
>> I'm glad we agree on the principles, but I don't think we agree on
>> the remedy.
>> This relates to ISSUE-4 ("html-versioning") and ACTION-93:
>>
>> It seems like we have four versioning mechanisms for content:
>>
>> * MIME type
>> * namespaces
>> * DOCTYPE
>> * version attribute on elements
>>
>> All of these have been rejected as ways of distinguishing XHTML5
>> from XHTML2,
>> for various reasons which have been analyzed:
>>
>> http://www.w3.org/QA/2007/05/html_and_version_mechanisms.html
>>
>> Only the namespace element is sufficient for distinguishing languages
>> in arbitrary generic XML  compound documents where there may not be
>> even
>> the possibility to specify the HTML version.
>>
>> So, I offer the following proposal:
>>
>> HTML5 isn't being designed for incorporation in arbitrary generic
>> XML compound
>> documents in any case.
>
> That would be an incorrect assumption. XHTML5 will be likely be used
> in compound documents in combination with, for example, SVG or XBL2.
>
>> So I would propose instead:
>> a)  XHTML5 *MUST NOT* be used in arbitrary generic XML compound
>> documents. Any
>>  use of the namespace in such contexts denotes XHTML2, not XHTML5.
>>  Since HTML5 and XHTML5 are not being designed for inclusion in
>> arbitrary
>>  XML compound documents, this should not have any impact in practice.
>
> Since this proposal is based on a false premise I do not think it is
> viable. Further, since user agents in practice support XHTML namespace
> elements in arbitrary XML compound documents, this would amount to
> requiring XHTML5 user agents to implement XHTML2, which is not a
> reasonable requirement.
>
>>
>> b) a new MIME type, application/xhtml5+xml, be allocated for XHTML5,
>> and a new
>>  MIME type, application/xhtml2+xml, be allocated for XHTML2, since
>> they both
>>  differ sufficiently from XHTML1.
>
> HTML 4.01 differs from HTML 3.2 and XHTML 1.0 yet all three can be
> served with the text/html MIME type. More importantly, though, user
> agents will likely process application/xhtml+xml (and indeed
> application/xml or text/xml) documents under XHTML5 processing rules
> rather than XHTML2 or XHTML1, so the new MIME type won't provide
> meaningful value.
>
>>   Since recommended practice is to deliver HTML5 as text/html in
>> any case,
>>  this should not have any serious impact in practice either.
>
> I would not assume what has impact in practice based on what is
> recommended. In practice, many things are commonly done that are not
> recommended.
>
> I prefer your original proposal to close this issue without action.
>
> Regards,
> Maciej
>
>>
>>
>> Larry
>> --
>> http://larry.masinter.net
>>
>>
>> -----Original Message-----
>> From: Maciej Stachowiak [mailto:mjs@apple.com]
>> Sent: Monday, February 16, 2009 10:43 AM
>> To: Larry Masinter
>> Cc: Lachlan Hunt; HTML WG
>> Subject: Re: What's the problem? "Reuse of 1998 XHTML namespace is
>> potentially misleading/wrong"
>>
>>
>> On Feb 16, 2009, at 10:21 AM, Larry Masinter wrote:
>>
>>> I think I wasn't clear enough, so let me try to clarify:
>>>
>>> In XML, namespaces identify vocabularies, not languages.
>>> Language definitions define rules for putting together
>>> vocabularies and user-supplied terms and procedures by
>>> which a receiver of an utterance in the language (a
>>> receiver) can interpret and understand the meaning
>>> intended by the sender of that utterance.
>>>
>>> You can have two different languages sharing the same
>>> namespace as long as there is sufficient information
>>> for any receiver of an utterance to determine which
>>> language was intended.
>>>
>>> Conclusion:
>>> XpMLq and XrMLs can share the same XML namespace
>>> as long as there is some way that you can determine
>>> which was intended, through MIME types, DOCTYPE
>>> or other means.
>>>
>>> This is true whether XpMLq and XrMLs are XHTML1
>>> and XHTML2, XHTML2 and XHML5 or XHTML5 and
>>> XHTML5.001 (an incremental update).
>>>
>>> Sharing namespaces with different languages is
>>> unacceptable if there is no other versioning
>>> mechanism than the namespace name. It would
>>> define two overlapping languages where there
>>> is no deterministic way of deciding which
>>> utterances were in which language, without
>>> extra contextual information. This is very
>>> bad language design.
>>
>> XHTML2 and XHTML5 both use the application/xhtml+xml MIME type, and  
>> do
>> not require a doctype declaration to be specified. XHTML2 has a
>> version attribute on the root element, but it is optional.
>> Furthermore, either may be used in a generic XML compound document
>> where there may not be even the possibility to specify the HTML
>> version via a root element attribute or doctype declaration. In
>> practice user agents assign semantics and behavior almost exclusively
>> based on the qualified name of an element, since there is no other
>> disambiguation or versioning construct that is present in all
>> contexts.
>>
>> Thus, I believe the use of the same namespace by XHTML2 and XHTML5
>> would be "unacceptable" and "very bad language design" by the  
>> standard
>> you set out above.
>>
>>> Whether or not there is any "vendor" who supports
>>> or is intending to support both XHTML2 and XHTML5
>>> is irrelevant to this question, since agents
>>> that cannot properly interpret an instance
>>> of the language they're presented with should
>>> not blindly try to interpret those instances
>>> in some other language.
>>
>> I was trying to say politely that XHTML2 is unlikely to ever be  
>> widely
>> implemented by mainstream Web software, so we shouldn't spend a lot  
>> of
>> the group's time worrying about ways it may conflict with XHTML5. If
>> someone were to invent a language that uses all the same words as
>> English but with different meanings, then in theory that would be bad
>> language design but that doesn't mean English speakers need to worry
>> about it a whole lot.
>>
>> To summarize, I definitely think there is a problem in theory, for  
>> the
>> same reasons you gave above. But I don't think it will be a problem  
>> in
>> practice.
>>
>> Regards,
>> Maciej
>>
>>
>>>
>>>
>>> Larry
>>> --
>>> http://larry.masinter.net
>>>
>>>
>>> -----Original Message-----
>>> From: Maciej Stachowiak [mailto:mjs@apple.com]
>>> Sent: Thursday, February 12, 2009 4:19 PM
>>> To: Larry Masinter
>>> Cc: Lachlan Hunt; HTML WG
>>> Subject: Re: What's the problem? "Reuse of 1998 XHTML namespace is
>>> potentially misleading/wrong"
>>>
>>>
>>> On Feb 11, 2009, at 12:46 PM, Larry Masinter wrote:
>>>
>>>>>
>>>>> But XHTML2 also has several major incompatibilities with XHTML1,
>>>>> which
>>>>> would effectively make it impossible to implement both XHTML 1.x
>>>>> and 2
>>>>> in the same implementation, if they share the same namespace [3].
>>>>
>>>> The fact that one language makes <title>abc</title> equivalent
>>>> to <meta property="title" content="Document Title"/> and the other
>>>> does not does mean the languages are incompatible. But the elements
>>>> "title" and "meta" have the same meaning as vocabulary items, their
>>>> usage is different in the two languages.
>>>>
>>>> I know that there is significant resistance to the idea that you
>>>> might
>>>> define a vocabulary independent of a language which uses that
>>>> vocabulary,
>>>> or that you might define a language independent of the processing
>>>> rules
>>>> by which instances of text in the language should be processed, but
>>>> those separations are fundamental to the design of XML, and the
>>>> question
>>>> here is about XML namespaces and their use.
>>>
>>> What Lachlan raises is an actual technical problem in the design of
>>> the languages, even if the languages have "the same vocabulary" in
>>> some sense. It is not possible to implement a user agent that
>>> conforms
>>> to both XHTML5 and XHTML2. In many cases the same elements or
>>> attributes are defined to have different processing requirements.
>>> Since DTDs are optional, and since elements in the XHTML namespace
>>> may
>>> appear in a compound document, there is no way to determine which
>>> processing requirements to use. XHTML2 also has this problem with
>>> regard to XHTML1.x.
>>>
>>> I don't believe any vendor currently plans to support XHTML5 and
>>> XHTML2 together in the same product, so perhaps this is not a  
>>> problem
>>> in practice. But it is still a design flaw in XHTML2 and should be
>>> fixed by the XHTML2 Working Group.
>>>
>>> Regards,
>>> Maciej
>>>
>>
>
>
Received on Monday, 16 February 2009 22:08:46 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:01 UTC