| home / programming / xforms / 1 |   [previous] |
|
|
|
Any document that uses XForms will necessarily be a combined document type, involving multiple XML namespaces. Such compound documents are still largely uncharted territory in the realm of W3C specifications, which leads to several headaches. For one thing, XML has the concept of attributes of type ID, specifying a document-unique value. Unfortunately, the id-ness of the attribute needs to be declared in a DTD or some kind of schema, which can only occur at the top of the overall document, not at the point where a subdocument starts. DTDs in general are poorly suited to validation, so until further work is done within the W3C, some XForms documents will have to suffice with being simply well-formed.
TIP: Although often scorned by developers, XML namespaces are a fact of life, particularly for W3C specifications. XForms elements conforming to the final W3C Recommendation are defined in a namespace of http://www.w3.org/2002/xforms. Other specifications could, in theory, include all the XForms elements in their own namespace, though this seems unlikely for official W3C specifications. Examples in this book show a mixture of both approaches.
One glimmer of hope is a recurring proposal for an attribute named
xml:id, which would be recognized as having id-ness
without a separate DTD or Schema. In examples throughout this book, any attributes
named id will be considered to have been appropriately
declared to be unique identifiers.
In a similar category is an attribute usually named class,
which serves as a hook for attaching style sheets. As used throughout this chapter,
the host language is responsible for defining this attribute and attaching it
to the XForms elements.
Another attribute, src, has caused
nearly as much controversy as its big brother in XHTML, href.
The problem stems from tension with XLink 1.0, a W3C Recommendation, which asserts
itself as the preferred technique to define any "explicit relationship
between resources or portions of resources." Originally, this standard
was envisioned by some as a solution that could apply to any XML, but the final
solution worked only with an attribute named xlink:href
(complete with a separate namespace).
The inflexibility of XLink causes problems in modularized documents,
including XForms, since there are different kinds of links but only one allowed
attribute name. As an example, an element might both serve as a launching point
for a hyperlink, and at the same time link to external inline content, as in
the following fragment that might result from a combination of XForms and SVG
(which uses xlink:href):
<xforms:label src="label2.svg" xlink:href="homepage.html"/>
In this example, the src attribute
from XForms points to a SVG file to be used as the label, and the xlink:href
attribute from SVG makes the label a clickable hyperlink to homepage.html.
It's a good thing that the XForms attribute is named src
and not xlink:href, because a conflict would have
resulted when trying to combine the languages, since an element can't have two
attributes with the same name.
As an alternative to XLink, the HTML Working Group proposed another
standard, called HLink, to annotate any XML with link descriptions. The proposal
met with almost as little enthusiasm as XLink. The Technical Architecture Group
(TAG) of the W3C is looking into the issue; the long term resolution remains
to be seen. Controversies aside, in XForms, src
consistently means one thing: that the URI in the attribute value is to be fetched
as part of loading the document, and the contents rendered in place of whatever
element contains the attribute (much like the img
element in earlier versions of XHTML)
| home / programming / xforms / 1 | [previous] |
Jupitermedia Corporation has two divisions: Jupiterimages and JupiterOnlineMedia
Legal Notices, Licensing, Reprints, Permissions, Privacy Policy.
Advertise | Newsletters | Tech Jobs | Shopping | E-mail Offers
Created: March 27, 2003
Revised: October 10, 2003
URL: http://webreference.com/programming/xforms/1
