RFC: New rootlevel CPAN namespace: XHTML

[jeffa]

After participating in the RFC: CGI::Tables thread, i felt an urge to improve my DBIx::XHTML_Table module by doing more than simply changing the internals. I would like decompose it into two modules (XHTML::Table and DBIx::XHTML::Table) and deprecate the original. However, to register XHTML::Table requires creating a new rootlevel namespace on CPAN. So, i must argue why CPAN needs an XHTML rootlevel namespace. I thought that arguing here first would be a good idea.

So, what is my argument? Because i want to. :P

Not a very good argument at all. That's why i seek your help. Now, two alternatives that i can accept are 1) simply keep DBIx::XHTML_Table and decompose the 'non-DBI' stuff into HTML::XHTML_Table, which would not require a new rootlevel. 2) I could also register DBIx::XHTML::Table and register HTML::XHTML::Table as it's base class. (I really would like to get rid of the underscores in the name.)

But, i have to also ask ... does CPAN need an XHTML rootlevel namespace, or is XHTML simply a subset of HTML (or vice versa)?

What do you think? Thanks in advance for your input. :)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

[hardburn]

I think XHTML is a subset of XML that defines tags in HTML. Strictly, there should be an XML::XHTML:: namespace. However, HTML and XML also happen to be subsets of SGML, but nobody made SGML::HTML:: or SGML::XML:: namespace, so there is at least precedent for making very-popular subsets into a namespace of its own.

I suspect that XHTML has quite a specific purpose and is widely used enough that it should be given its own namespace. The XML:: namespace seems mostly filled with parsers or generators, and not with specific uses of XML.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

[mirod]

Yipee! Yes! Yes! Yes! We need a new top level namespace, so we can fill it with XHTML::Simple, XHTML::Simpler, XHTML::Simplest, XHTML::Easy, XHTML::Easy::Simple and XHTML::HardButStandardAndJavaLike! ;--)

Seriously now... I am not sure there is a need for a new namespace: the boundaries between HTML, XHTML and XML are quite fuzzy, a lot of HTML modules can happily deal with XML input, a lot of XML modules have no problems with HTML input (libxml2 has an HTML mode, so all modules based on it can read HTML). Plus XHTML is really pushed by the W3C as just the natural evolution of HTML, so why differentiate them? I am not sure it would make it easier for users, who would have to look at one more namespace, beyond HTML and XML (plus DBIx and a couple of others).

In your specific case would XHTML::Table be very different from HTML::Table? If yes then the similarity in the names will confuse users, if not why not patch it to make it work nicely with DBIx::XHTML::Table?

[jeffa]

Thanks for replying mirod. Personally, i think that HTML::Table is (sorry for being so harsh) less-than-CPAN-worthy. (have you looked at the source for that module?) It's, IMHO, just not a good, generic solution to the problem at hand. I would actually like to take it over from the author, but that seems mean. As i said before, i would be perfectly happy with HTML::XHTML::Table, but in retrospect, i really wish that i had registered HTML::Table before Mr. Peacock did. :(

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

[tye]

Why is it "mean" to improve someone else's work? The only hope for CPAN to "scale" is for this attitude of "Don't touch my/his/her module!" to go away.

We all have blind spots. In my experience, the best software has been touched by several hands, each making improvements that the previous author was (relatively) "blind" to.

Also, once one succeeds at the challenge of getting a module working well enough to bother to upload it to CPAN, the motivation to work on it will typically decrease, often by a large amount.

Your first choice should be to improve an existing CPAN module. The idea of taking your turn at "taking over" the module should not be an unpleasant thought. Nor should the thought of letting someone else take over for you (if you aren't up to directing the merging of their improvements in). I'd think that most new authors would allow previous authors to have influence on the module if they wish to.

Try to think of the greater, common good. Be respectful of each other and of the history/heritage of the module, but please don't run away from making one really great module instead of yet another similar (better in at least some ways) module such that it just continues to get harder and harder to pick which module to use.

                - tye

[mojotoad]

As i said before, i would be perfectly happy with HTML::XHTML::Table, but in retrospect, i really wish that i had registered HTML::Table before Mr. Peacock did. :(

Mr. Peacock did not...the original author was Stacy Lacy, who had looked for volunteers, once upon a time, to take over the module. There were no takers. Two or three years later, Mr. Peacock came along with some enhancements, but could not contact Stacy Lacy and asked the perlmod mailing list whether he could take over the module so that his enhancements could be implemented. Since I still had the original request from Stacy Lacy (1998), I forwarded it along to the list and presto, Mr. Peacock was the new owner.

That particular namespace has been around for quite some time.

Matt

[diotalevi]

I don't see XHTML as being that drastic a departure from HTML that it needs to be separate. Right now, the current state of affairs has us treating most XHTML as stricter HTML. Perhaps as the semantic web picks up people will come up with other, better things to do with it and XHTML might a base for real, non-HTML-like activities. You said "does CPAN need an XHTML rootlevel namespace, or is XHTML simple a subet of HTML." I want to turn that statement on its head and see what the stress points are between XHTML and HTML and see if that leads us anywhere.

[kal]

Personally, I would say yes, new namespace. Because I think an XHTML module should be a radical departure from HTML, not in terms of it's output, but in terms of it's construction.

An XHTML module should - by default - be built using the existing XML tools, and shouldn't be outputting 'XML-like code' but actual machine-generated bona-fide XML.

From the otherside, outputting XHTML and using it in a HTML context is almost as bad as outputting non-XML in an XHTML context. <br />, for example, is invalid markup in HTML4.0 (strictly speaking). Of course, browsers will ignore the '/' but you're giving up clean HTML and getting tag soup. Some browsers, especially Moz, might even start going into almost-standards most/quirks mode, or something, which is even worse.

Strictly speaking, I don't think one is a subset of the other, but I would love to see how you propose to do XHTML modules. By thinking about implementation, I'm probably thinking on very different lines to you (or am I?).

[jeffa]

I agree that my module should use existing XML tools, but right now the only dependency is DBI ... i guess i really am outputting 'XML-like' markup that happens to be valid (right now ...)

If i do get to take over HTML::Table, i will most likely add the option to choose HTML or XHTML. But i do see a problem in generating 'bona-fide' XML because the output of my module is simply a piece of an entire XML document. Correct me if i am wrong, but most XML tools that i have worked with insist on some sort of 'header' ... and this module does not need to do that - that responsibility belongs to the 'container' document which will hold the resulting table.

Thanks for your input. :)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

[kal]

You're right about the fragmentation issue - that is something that conceivably stop someone outputting valid X/HTML. But that would be the kind of implementation issue that a XHTML:: module should support - chaining of object serialization, for example, could solve the problem in a nice way.

My hope for anytbing XHTML:: would not be that it would output mostly XHTML, but that it would guarantee to output valid XML at least. That would be the selling point for me. Unfortunately, XML is a little unwieldy in Perl in some respects (thinking mostly about accessibility of modules on common systems), but what the hey.

I don't think many people get the benefits of XHTML yet. For example, I had validated my site as XHTML for quite a while before delivering the content with the correct MIME type. Mozilla had a big surprise in wait for me when I did that - it doesn't render non-XML pages. That is why an XHTML:: module must guarantee XML output - you can't actually do 'correct' XHTML without it (or, you can try, but Mozilla won't display anything other than an error message).

[Aristotle]

Personally I don't think so. XHTML is basically a diversification of HTML; I don't see the point in differentiating between the two so strictly as to have them in different root namespaces. If it's really important, HTML::XHTML:: seems like the best place to put it.

My preferred course of action would be to take over HTML::Table and support its current interface as a stub to delegate to a newly created HTML::XHTML::Table module. They should probably both be within the same distribution. The POD for HTML::Table would be updated to point out that this module is being deprecated in favour of HTML::XHTML::Table.

Makeshifts last the longest.

[Abigail-II]

Frankly, I don't see the point in discussing whether "CPAN needs an XHTML rootlevel namespace" in this forum. Perlmonks doesn't control CPAN, perlmonks isn't the sole user of CPAN, nor does perlmonks run the modules mailinglist. The latter is the place to ask, if you want to bother asking them (I certainly wouldn't).

There isn't any technical reason you should ask permission. If you think XHTML::Table is a good name, just upload it to PAUSE, and it will be distributed over the mirrors and people will be able to install XHTML::Table. About all that can happen is that the module cabal won't like you choice and the module name won't appear on some list. Big deal. CPAN is quite anarchistic, and it works very well that way.

Personally, I'd use XML::XHTML::Table, but then, I would have used SGML::HTML::* instead of HTML::* as well.

Abigail

[jeffa]

Point taken, but it's my only forum!. Seriously, Perlmonks really is the only place that i feel comfortable asking such a question. I figure that even though Perlmonks does not control CPAN, there are a LOT of CPAN authors here with valid opinions. I am glad that even though you don't see the point in this discussion here, you participated anyway. Thank you for your insight. :)

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

[Abigail-II]

Point taken, but it's my only forum!

If perlmonks was the only forum I participate in, should I ask "butter or margerine?" here as well? ;-)

Abigail

[Anonymous Monk]

USENET called, they want their attitude back!

If I'm not mistaken, Perlmonks is a site about Perl. It's not comp.perl.language.only it's Perlmonks. This would lead me to believe all issues about Perl are welcome here. CPAN is definately related to Perl, in fact, it is the very heart of Perl, so why shouldn't it be discussed here?

Nobody claimed perlmonks controls CPAN, the module list, or is the only user of CPAN. However, This doesn't mean we can't discuss issues related to CPAN here. Posting module RFCs or questions about namespaces here can only help CPAN. It serves as an extra source of insight and a filter to point out potential problems before bothering the CPAN people with them.

You should have just pointed out that following the discussion here, jeffa should post to the CPAN list as well. Not bothered with the "perlmonks don't own us" speech. If you have something against this site, kindly check it at the door. Unnecessary stifling of constructive discussion is of little use.

:)

[Abigail-II]

Did I say it shouldn't be discussed here? I just said I don't see the point. Supposed 1000 people here say "yes, it does belong there", and the modules list says "no", then what? Or 1000 people here say "no, it doesn't", the OP changes the name of his package, and next week, someone else creates XHTML::DancingSquirrels and the modules list says "Cool, we finally have an XHTML rootlevel namespace".

My point is that perlmonks doesn't control CPAN. CPAN does not have an open forum to discuss which namespaces are "official", but in practise, anything goes anyway, whether blessed by the cabal or not.

So, I remain with my standpoint that I don't see the point of discussing it. And note that the OP didn't ask "do you consider this a good name for my module?", he specifically asked about whether that toplevel namespace should be on CPAN.

Abigail