Re: [xml-dev] XHTML 2 Working Group won't be renewed?

[David Orchard <orchard@pacificspirit.com>]

I'm absolutely +ve that TBL shares your pov.  I led a TAG day long
effort last year during our KC f2f trying to figure out how the TAG
could get to consensus on supporting distributed extensibility in
HTML5, but sadly no luck.

What I'm hoping will happen is that the browser vendors will actually
not be draconian in the interests of their backwards-compatibility
mantra and allow namespaced elements and attributes to go through into
the DOM without ignoring or even worse rejecting.  And the world can
maybe just do what it should be able to do.

Otherwise the world is going to get really weird with all sorts of
structured attributes popping up in class etc.  I can just see the
jquery and css 4 modules for parsing xml structures in attributes.

Cheers,
Dave

On Wed, Jul 8, 2009 at 1:24 PM, Jim Melton<jim.melton@oracle.com> wrote:
> Kurt gave my arguments in a much more elegant way than I would have done, so
> I thank him.
>
> Dave raises what I consider to be a critical point -- and I suspect that
> TimBL will share my opinion: Does any single group have the right to
> determine every element and attribute that can be used on the World-Wide
> Web?  My answer is derisive laughter and scoffing.  No single group, not
> even the W3C itself, has -- or should have -- that right.  The whole point
> of the Web (1.0, 2.0, 3.0, 12.15, whatever) is extensibility.
>
> While lazy and careless programmers might love getting away with coding
> random strings of characters and having them do "cool" things in browsers,
> the Web belongs to all the world, not only such programmers or the people
> sitting at their screens being thrilled at the cool effects they can see.
>
> Of course, if the W3C were to put its metaphorical foot down and say "No
> way, never" to that crowd, it won't change a thing, except that the
> development will occur under the auspices of some other organization,
> probably one more interested in asserting authority than in developing
> usable standards.
>
> It's hard to know just what to do about this problem. Should W3C trademark
> the name "HTML" and many possible variants? Should it lock proponents of
> both sides of the debate into a tiny room and require them to reach an
> agreement before being allowed out to go potty? Should it throw up its hands
> and say "We can't control it, so we'll just let it happen"?
>
> If browser developers in just 5 or 6 organizations can be persuaded of the
> value of discipline and organization, the debate will die a deserved death
> and sanity may be increased.  Experience suggests that such persuasion is,
> ummm, unlikely.
>
> Hope this helps,
>   Jim
>
>
>
> At 7/8/2009 01:46 PM, David Orchard wrote:
>>
>> Kurt,
>>
>> The hixie, etc. crowd pushback on namespaces is not just about ease of
>> authoring, it's more about control over language evolution.  The whole
>> point of namespaces is to allow distributed extensibility, and the
>> non-namespace html5 crowd wants all element and attribute definitions
>> to be done through the html5 wg and mostly through the html5
>> specification.  Wherever there is disagreement between html5 wg and
>> another wg on element/attribute definitions, the html5 wg will decide
>> what will be allowed and on what schedule.  See every single
>> discussion with a non-html5 party, such as aria, rdfa, svg, mathml.
>>
>> Cheersl,
>> dave
>>
>> On Wed, Jul 8, 2009 at 12:28 PM, Kurt Cagle<kurt.cagle@gmail.com> wrote:
>> > The problem that xhtml 2.0 faced (and any xhtml adoption for that
>> > matter) is
>> > that you're still dealing with the Coding Granny Argument, something
>> > that is
>> > used extensively by the HTML purist crowd who frankly do NOT want to see
>> > XML
>> > adopted as a lingua franca, especially
>> > for expressing HTML.
>> >
>> > Most of you have seen the argument, of course. It runs along the lines
>> > of
>> > "HTML has to be accessible to non-programmers. My grandmother should be
>> > able
>> > to write HTML code, even if its ill-formed, and have the browser
>> > magically
>> > "know" what was the intent of such code, otherwise there will be no
>> > adoption
>> > of HTML.
>> >
>> > In practice, this argument is specious in the extreme.  The eponymous
>> > coding
>> > granny is far more likely  to be writing in a blog engine or wiki in
>> > which
>> > the input of content is almost certainly going to be filtered into a
>> > final
>> > form for storage, they will likely end up using perhaps two tags, <i>
>> > and
>> > <b>, and may even by using a WYSIWYG editor that will let her
>> > incorporate
>> > code programatically. It is not, in fact, this user that the argument is
>> > intended to protect, but rather the coder with bad programming habits.
>> >
>> > Most framework libraries are unfortunately written by people who may be
>> > good
>> > Java or Python or JavaScript of PHP programmers but who have either been
>> > seduced by the notion that HTML can be lazy or are in fact just sloppy.
>> > The
>> > irony, of course, is that in nearly all computer languages, if you
>> > violate
>> > syntactical rules, the program won't compile. Why HTML has to be the one
>> > language that violates this has never been clear. What's even worse, I
>> > can
>> > see it for HTML 4.1, because that language was approved at a time when
>> > HTML
>> > was still coded largely by hand, and as such there is a large block of
>> > legacy code that needs to be supported. However, why HTML 5 needs to
>> > conform
>> > to this absurdity is still beyond me, and I've yet to see a truly valid
>> > reason for not mandating just an XML format.
>> >
>> > There is a second facet to these arguments. The HTML crowd hates, fears
>> > and
>> > despises namespaces. Again namespaces mess too much with the Coding
>> > Granny
>> > argument, and they add to the complexity of writing inline HTML content
>> > for
>> > all of those AJAX programmers who tend to think that the only relevant
>> > angle
>> > bracket language is HTML. If Ian Hixie acknowledges the XML argument,
>> > then
>> > he also has to acknowledge the validity of namespaces, and I suspect
>> > this is
>> > a non-starter for him. By keeping the two languages "separate but equal"
>> > he
>> > gets his namespace free language and can then work towards eliminating
>> > namespaces from the spec down the road.
>> >
>> > There's supposed to be an extensibility workshop in September at one of
>> > the
>> > F2Fs where namespaces in general will be hashed out - I plan to be
>> > monitoring that one carefully, as I suspect that there will be a move to
>> > "fix" namespaces in a way that will have long term negative
>> > repercussions
>> > for the XML community.
>> >
>> > Kurt Cagle
>> > Managing Editor
>> > http://xmlToday.org
>> >
>> >
>> > On Wed, Jul 8, 2009 at 11:51 AM, Jim Tivy <jimt@bluestream.com> wrote:
>> >>
>> >> We have an Xml content management system.  We currently have a customer
>> >> prospect seeking SGML support.  Turns out few vendors are supporting
>> >> SGML
>> >> anymore and we never plan to support it.  What this means to Xml
>> >> content
>> >> management is SGML and HTML gets stored as binary files - there being
>> >> two
>> >> kinds of files in our system: Xml and Binary.  Whereas, XHTML is stored
>> >> as
>> >> Xml and is thus enabled for the full processing capable - including
>> >> link
>> >> mining and checking.
>> >>
>> >> Whether HTML-5 is the path to a fully Xml compliant XHTML (including
>> >> namespaces) or whether XHTML-2 is I don't know.  Seems like XHTML 1 and
>> >> 1.1
>> >> have established XHTML.
>> >>
>> >> I think SGML needs to die out as do its descendants like HTML.  The W3C
>> >> should say in the HTML5 specification that the SGML serialization is
>> >> deprecated. Perhaps new features do not have an SGML serialization. I
>> >> really
>> >> don't think young people are learning SGML and I never plan to learn
>> >> it.
>> >>
>> >> As a small point, perhaps a mime type called text/xhtml needs to be
>> >> used
>> >> rather than the longer application/xhtml+xml.
>> >>
>> >> As well, I thought the buzz on the street for website builders was to
>> >> use
>> >> XHTML transitional.
>> >>
>> >> Jim
>> >>
>> >>
>> >>
>> >> _______________________________________________________________________
>> >>
>> >> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> >> to support XML implementation and development. To minimize
>> >> spam in the archives, you must subscribe before posting.
>> >>
>> >> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> >> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> >> subscribe: xml-dev-subscribe@lists.xml.org
>> >> List archive: http://lists.xml.org/archives/xml-dev/
>> >> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>> >>
>> >
>> >
>>
>> _______________________________________________________________________
>>
>> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
>> to support XML implementation and development. To minimize
>> spam in the archives, you must subscribe before posting.
>>
>> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
>> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
>> subscribe: xml-dev-subscribe@lists.xml.org
>> List archive: http://lists.xml.org/archives/xml-dev/
>> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>
> ========================================================================
> Jim Melton --- Editor of ISO/IEC 9075-* (SQL)     Phone: +1.801.942.0144
>  Chair, W3C XML Query WG; XQX (etc.) editor       Fax : +1.801.942.3345
> Oracle Corporation        Oracle Email: jim dot melton at oracle dot com
> 1930 Viscounti Drive      Standards email: jim dot melton at acm dot org
> Sandy, UT 84093-1063 USA          Personal email: jim at melton dot name
> ========================================================================
> =  Facts are facts.   But any opinions expressed are the opinions      =
> =  only of myself and may or may not reflect the opinions of anybody   =
> =  else with whom I may or may not have discussed the issues at hand.  =
> ========================================================================
>