[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

How to get realistic expectations for Namespaces (was Best Practice = Va

• To: <xml-dev@l...>
• Subject: How to get realistic expectations for Namespaces (was Best Practice = Vanilla XML? )
• From: "Rick Jelliffe" <ricko@a...>
• Date: Fri, 23 Aug 2002 07:01:14 +1000
• References: <200208212113.RAA13444@m...> <200208220017.g7M0HM331421@d...> <00c601c249a0$d269a890$32f5d90c@c1980223a> <p04330100b98a7fd96bad@[192.168.254.4]> <00f401c24a12$07c1bfc0$54d83744@e...>

From: "Ken Sall" <kensall@c...>

> > 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

• Follow-Ups:
  • Re: How to get realistic expectations for Namespaces (was Best Practice = Vanilla XML? )
    • From: John Cowan <jcowan@r...>

• References:
  • Re: A multi-step approach on defining object-orientednatureof DOM
    • From: John Cowan <jcowan@r...>
  • Re: A multi-step approach on defining object-orientednatureof DOM
    • From: Joe English <jenglish@f...>
  • Best Practice = Vanilla XML? (was A multi-step approach on defining object-orientednatureof DOM)
    • From: "Jeff Rafter" <jeffrafter@d...>
  • Re: Best Practice = Vanilla XML? (was A multi-stepapproach on defining object-orientednatureof DOM)
    • From: Elliotte Rusty Harold <elharo@m...>
  • Re: Best Practice = Vanilla XML? (was A multi-step approachon defining object-orientednatureof DOM)
    • From: Ken Sall <kensall@c...>

• Prev by Date: Re: A multi-step approach on defining object-oriented nature of DOM
• Next by Date: Re: How to get realistic expectations for Namespaces (was Best Practice = Vanilla XML? )
• Previous by thread: Re: Best Practice = Vanilla XML? (was A multi-step approachon defining object-orientednatureof DOM)
• Next by thread: Re: How to get realistic expectations for Namespaces (was Best Practice = Vanilla XML? )
• Index(es):
  • Date
  • Thread