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

Re: Another look at namespaces

  • From: David Megginson <david@m...>
  • To: "XML-DEV" <xml-dev@i...>
  • Date: Thu, 16 Sep 1999 05:14:32 -0400 (EDT)

mailto mime
Tim Berners-Lee writes:

 > >Tim Berners-Lee writes:
 > >
 > > > What happens when a version one program meets a version 2 document?
 > >
 > >As Tim points out, this is (or at least, should be)
 > >application-specific.  I have omitted his summary, but I agree
 > >with its broad outlines.
 > 
 > I'm not sure what you mean by "application -specific".  If you mean
 > that one is entitled to do feed a document into any app program and
 > depending on what the program does anything can happen, and be
 > taken as a valid interpretation of the document, then no!

No, that's not quite what I mean -- I mean a combination of
"application" in the SGML sense (i.e. the XHTML Namespace or document
type) and "application" in the marketing sense (i.e. a Web browser).

It's difficult for a designer to anticipate all of the expected uses
of a Namespace -- for example, it's quite reasonable to specify what
*browsers* should do when the find an unknown element type in an HTML
document, but should the same behaviour apply to (for example) to
search engines and text repositories?  I'd be very upset if an XML
repository automatically stripped out unrecognized element boundaries
when I checked in an XHTML document.

 > My point was that the combination of the document and the
 > definition of the language it is written in have a certain meaning
 > and that nothing must be allowed to produce a different
 > (contradictory or superset) meaning ostensibly from the original
 > document.

Yes, but unless the Namespace is irrevocably tied to a very specific
processing model, its definition (human-readable or otherwise) will
necessarily provide only partial information.  The Namespace
definition says *what*, but it cannot usually say *how*.

 [snip]

 > Here you introduce a distinction between a "general language" and
 > a "dialect".   I am not convinced that this is a well-defined concept.
 > I feel that language subsets are completely well defined, by the change
 > of namsespace preserving validity.
 > What is the definition of a "dialect"?

The boundary between dialect and language is not crisp.  I am
absolutely certain that C++ and HTML are different languages, and I am 
fairly certain that HTML 4.0 transitional and HTML 4.0 strict are
different dialects of the same language, but I don't know where to
draw the line in the middle: are C and C++ (for example) different
dialects or different languages?

As with natural language, the best test is interoperability, even if
the results are not always conclusive (as in my C/C++ example).  My
Web browser works more-or-less properly with HTML 2.0, HTML 3.2, HTML
4.0, and XHTML, without knowing in advance which of those it's going
to see (all it gets is the MIME type text/html) -- for me, that's
proof that they are all dialects of the same language.  Certainly, a
multi-billion dollar industry is based on that assumption.

 > To me, nesting a level of naming of "version" inside a "general"
 > language suggets that nothing at all is really known about the
 > general langauge.

That's obviously a deliberate overstatement -- Netscape and MSIE work
most of the time, even though they work at what I'm calling the
language level; we're simply dealing with a 20,000-foot view rather
than a 2,000-foot view.

It's not a perfect analogy, but take a look at a MIME type like
text/html or image/jpeg -- it is often possible to perform useful
sorts of processing on all image/* or text/* resources.  Two-level
hierarchies are well-proven and well-deployed, and in the case of a
language (Namespace URI) and dialect (version) pair, the two levels
will provide much more precise information than a MIME type.


All the best,


David

-- 
David Megginson                 david@m...
           http://www.megginson.com/

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.