Feature Requests item #1493590, was opened at 2006-05-23 13:24 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1493590&group_id=119783
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: core Group: 1.2 Status: Open Priority: 5 Submitted By: Benjamin Hawkes-Lewis (webben) Assigned to: Nobody/Anonymous (nobody) Summary: Document type and definition for the Wicket markup language Initial Comment: (Warning: I recommend reading this Feature Request over a mellow glass of wine or a good cup of coffee, because although important it is going to be very boring. Don't say I didn't warn you.) ----------------------------------------------- PROLOGUE: (RE)INTRODUCING WICKETML Wicket comes with its own set of tags and attributes (http://www.wicket-wiki.org.uk/wiki/index.php/Tags) that constitute a markup language. From here on in, I shall refer to this as WicketML, following the W3C's pattern with MathML (see http://www.w3.org/Math/). Just like MathML, WicketML is mostly used to add functionality to other markup languages. Currently, WicketML is only used with (X)HTML, but in the future it may be used with other markup languages such as XForms (see Eelco Hillenius's Feature Request 1440048 at http://sourceforge.net/tracker/index.php? func=detail&aid=1440048&group_id=119783&atid=684978). There are (at least) two ways of adding functionality to an existing markup language. The *first* way is to declare an additional namespace within a document. The XHTML 1.0 specifications give an example of this with XHTML and MathML (see http://www.w3.org/TR/2001/REC-MathML2- 20010221/dtd/xhtml-math11-f.dtd). An example using WicketML instead of MathML might look something like this: <html xmlns="http://www.w3.org/1999/xhtml"; xmlns:wicket="http://wicket.sourceforge.net"; xml:lang="en" lang="en"> <head> <title>Adding WicketML with a namespace</title> </head> <body> <p wicket:id="greeting">Hello world!</p> <body> </html> I think the current choice of namespace for Wicket is a mistake, but this particular Feature Request is not going to discuss the first method any further. Instead we are going to focus on the second method, which uses a custom document type. For an example of a custom document type being used to graft another markup language onto XHTML, please see http://www.w3.org/TR/MathML2/appendixa.html#parsing.module . An example using WicketML instead of MathML might look like this: <!DOCTYPE html PUBLIC "-//Wicket Framework//DTD XHTML 1.0 Strict plus WicketML 2.0//EN" "http://www.wicketframework.org/wicketml/2006/2/dtd/xhtml1-strict-wicketml2.dtd";> <html> <head> <title>Adding WicketML with a custom document type</title> </head> <body> <p wicket:id="greeting">Hello world!</p> </body> </html> Let's unpick the content of the DOCTYPE declaration. The first blob of text in quotation marks after PUBLIC is the formal public identifier (FPI) of the document type, which must follow naming rules laid down by the W3C and ISO. See http://www.w3.org/TR/2001/REC-xhtml-modularization-20010410/xhtml- modularization.html#s_conform_naming_rules and http://www.oasis-open.org/cover/petersonFPI- TAG7030101.html for more information on the specifics. My example FPI makes two working assumptions: 1) That the "organisation" (loosely speaking) responsible for the document type is "Wicket Framework". 2) That the document type grafts WicketML version 2 onto XHTML Strict version 1.0. The second blob of text in quotation marks after PUBLIC is technically the system identifier of the document type; but for our purposes the important thing is that it is a live, permanent URL pointing to the document type definition (DTD) file. Currently, two old variations on XHTML plus WicketML are available as DTDs from http://www.wicketframework.org/DTD: 1) wicket-1.0-xhtml11.dtd (added 13 April 2005) 2) wicket-xhtml1-strict.dtd (added 10 June 2005) In addition, a copy of wicket-xhtml1-strict.dtd is bundled with the current 1.2 sourcecode in the Wicket subversion repository (I haven't looked into what happened with earlier versions). This won't do. The DTDs are not up-to-date, the URLs and filenames fail to follow any logical pattern, and the current URL cannot cope with changes to WicketML because it does not include a versioning system. ---------------------------------------------- ADVANTAGES OF DEFINING WICKETML PROPERLY There are three major advantages of defining WicketML properly: 1) Should allow validation of documents before processing. 2) Should allow code completion of wicket elements and attributes. In some editors, this might be true even if WicketML is only included via a namespace, rather than via the document type. 3) Should provide a *definitive* description of elements and attributes processed by Wicket. Now I'm going to offer a few recommendations. (Hey! Stop nodding off!) ----------------------------------------------- RECOMMENDATION 1: A PERMANENT URL FOR EACH DTD I recommend that a copy of the DTD suitable for use with (at least) the next version of Wicket and XHTML 1.0 Strict be placed at: http://www.wicketframework.org/wicketml/2006/2/dtd/xhtml1-strict-wicketml2.dtd This naming system has several virtues. It is hierarchically organised. It is roughly patterned after the W3C's own system. It can easily be expanded to include document types that meld WicketML with languages other than XHTML 1.0 Strict (e.g. http://www.wicketframework.org/wicketml/2006/2/dtd/html401-strict- wicketml2.dtd or http://www.wicketframework.org/wicketml/2006/2/dtd/xhtml-xforms1-wicketml2.dtd). It can easily cope with the evolution of WicketML (eg. http://www.wicketframework.org/wicketml/2010/46/xsd/xhtml2-wicketml46.dtd). I should emphasise that the "2" in my suggested URL is the version of WicketML *not* the version of the Wicket codebase. It should be possible to iterate the Wicket codebase through minor changes (e.g. from Wicket 1.2 to Wicket 1.2.1) without requiring the creation of new DTDs that simply duplicate previous DTDs. I chose 2 because it is a good number with which to recognise, and transcend, WicketML's confused backhistory. ----------------------------------------------- RECOMMENDATION 2: ACCURATE DTDS The DTD bundled with the 1.2 sourcecode in the Subversion repository is currently commented as though it were the W3C's own "Extensible HTML version 1.0 Strict DTD"! The Wicket codebase currently has good versioning, authorship, and descriptive comments; this system needs to be extended to the DTDs for WicketML. (The earlier version at http://www.wicketframework.org/DTD/wicket-1.0-xhtml11.dtd did this a little better, but not much.) If a document type definition is to have any point at all, it *must* correctly describe the tags to be used in conforming documents. The current DTD fails at this crucial task, and is therefore not merely useless but *actually counterproductive*. I have not assessed whether the current DTD accurately includes information about XHTML 1.0 Strict tags, but I have compared the DTD with the wiki's account of WicketML (http://www.wicket-wiki.org.uk/wiki/index.php/Tags). The DTD includes an attribute not mentioned on that wikipage: wicket:preview. But out of the elements and attributes mentioned on the wiki (http://www.wicket-wiki.org.uk/wiki/index.php/Tags), the DTD currently mentions only the wicket:id attribute! It lacks any reference to: * wicket:link (element) * the wicket:remove (element or attribute?) * wicket:panel (element) * wicket:border (element?) * wicket:body (element?) * wicket:extend (element or attribute?) * wicket:child (element or attribute?) * wicket:head (element) * wicket:component (element with a "class attribute" in what namespace?) ----------------------------------------------- RECOMMENDATION 3: REVISE THE INTRODUCTION Reading some parts of the "Most existing frameworks require special HTML code" section of the introduction to Wicket (http://wicket.sourceforge.net/Introduction.html), one might be fooled into thinking that Wicket uses the "pure" HTML purportedly familiar to web designers. Given the existence of WicketML in all but name, it might be worth being a bit more accurate in our descriptions of Wicket's markup. Some obvious sentences which could do with revision in the introduction include: 1) "Instead, it extends HTML in a standards-compliant way via a Wicket namespace that is fully compliant with the XHTML standard." This is vague. According to the specs (http://www.w3.org/TR/xhtml1/#well- formed), documents that use XHTML with other XML namespaces "are not strictly conforming XHTML 1.0 documents". 2) "To accomplish this, Wicket consistently uses a single id attribute in the Wicket namespace ("wicket:id") to mark HTML tags that should receive special treatment by the toolkit." As you can see from the list above, there's now rather more to WicketML than "a single id attribute", whether we like it or not. 3) "This means that you can use Macromedia Dreamweaver, Microsoft Front Page, Word, Adobe Go Live, or any other existing HTML editor to work on your web pages and Wicket components." Has this actually been verified of all the weird Wicket elements and attributes listed above? I think the section needs to be redrafted to make a clear distinction between: a) input code and output code and b) the output of documents which still include the Wicket namespace and the output of documents from which the Wicket namespace and its elements and attributes have been entirely removed. The revised introduction should get down to specifics. Rather than waffling on about "pure-and-simple HTML", it needs to mention exactly what document types Wicket can work with and produce. Good web designers understand this stuff. They read A List Apart: * http://www.alistapart.com/articles/customdtds2/ * http://www.alistapart.com/articles/customdtd/ * http://www.alistapart.com/stories/doctype/ * http://www.alistapart.com/articles/dreamweaver/ ----------------------------------------------- FOR FURTHER DISCUSSION: ARE DTDS SUITABLE? Chatters at ##wicket IRC have suggested that DTDs cannot support namespaces. Wikipedia claims that DTDs have been criticised for having "[n]o support for newer features of XML â most importantly, namespaces" (see http://en.wikipedia.org/wiki/Document_Type_Definition#DTD_criticisms_and_alternatives). Now I am no XML expert, and it certainly seems to be true that DTDs do not exist in a namespace *themselves*. But it is far from obvious to me that DTDs have *no* support for namespaces. See http://www.rpbourret.com/xml/NamespacesFAQ.htm#q4_3 for a discussion of DTDs and namespaces. As far I can understand Ronald Bourret's discussion, the key point is that namespaces must be redeclared on prefixes in instance documents even if they are already declared in their DTDs. For example, even if http://www.wicketframework.org/wicketml/2006/2/dtd/xhtml1-strict-wicketml2.dtd were to declare that the wicket prefix refers to the http://wicket.sourceforge.net namespace, a parser would not recognise the wicket prefix in examplewicketpage.html as referring to that namespace and would throw an error. To avoid this, namespaces must be explicitly declared with a xmlns:wicket="http://wicket.sourceforge.net"; in the instance document. I believe this is why conforming XHTML documents always declare the namespace for the null prefix (i.e. for unprefixed elements/attributes) in the html element, like so: <html xmlns="http://www.w3.org/1999/xhtml";> If the W3C thought DTDs were suitable for MathML and the modularisation of XHTML, I don't really see why they can't be used for WicketML. But if it is decided that DTDs are not suitable, some other standard should be chosen for WicketML, such as the W3C XML Schema (XSD) or ISO's RELAX NG. ---------------------------------------------- COMING SOON TO AN ISSUE TRACKER NEAR YOU... A (hopefully shorter) discussion of the first method of melding markup languages using namespace declarations and what needs to be done to properly implement that in Wicket. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1493590&group_id=119783 ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Wicket-develop mailing list Wicket-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-develop
