[
Lists Home |
Date Index |
Thread Index
]
From: "Ken Sall" <kensall@comcast.net>
> > Sure you can. This is exactly what modular XHTML is designed for. The
> > specs give detailed instructions for how to mix your own vocabularies
> > into XHTML by setting the appropriate parameter entity references in
> > a driver DTD.
>
> Perhaps a more accessible starting point would be W3C's tutorial, "XHTML
> Modules and Markup Languages - How to create XHTML Family modules and markup
> languages for fun and profit" [1]
>
> [1] http://www.w3.org/MarkUp/Guide/xhtml-m12n-tutorial/
XHTML also provides evidence of the unacceptability of namespaces for certain uses.
The ruby module should have been a prime candidate for having its own namespace.
After all, the purpose of namespaces was to allow modularity. But rubies were added
to the XHTML namespace because otherwise people might think they were of less
status than HTML elements, and because of doubts over the practicality of people
getting right declarations for multiple namespaces.
Contrast this with MathML, which has its own namespace. Perhaps large vocabularies
and large insertions are good candidates to be separate namespaces,
but for small elements sets (like Ruby, with only a handful of elements) it is
too much trouble. Maybe we can say the same for XLinks: people don't
seem to like the fiddliness of the xmlns:* attributes.
Anyway, the Namespaces spec has been out for long enough now that we can
see where it has succeeded or failed. Isolating the reasons for its successes
and failures in various applications would give us a more rational basis
for utilizing it well.
For example, apart from the xml: and xmlns: built-in namespaces, has there
even been any QNamed attributes that have succeeded? Or any
QNamed inline elements (not having an ancestor in the same namespace)?
Cheers
Rick Jelliffe
|
