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

Re: Another look at namespaces

• From: David Brownell <david-b@p...>
• To: "Steven R. Newcomb" <srn@t...>
• Date: Tue, 21 Sep 1999 09:24:30 -0700

"Steven R. Newcomb" wrote:
> 
> [David Brownell:]
> 
> > You're conflating reliable information interchange with schemas, I
> > think.
> 
> Perhaps.  I confess that I don't understand how reliable (but
> system-vendor-neutral) information interchange is possible without
> insisting that the interchanged information conforms to some model.

... that model doesn't need to be "schemas".  Which I've observed seem
to be regularly invoked as the Silver Bullet that solves all problems.


> > Schemas, DTDs, and rules of all kinds are only aids to help achieve
> > goals ... and those goals can often be achieved without "excessive"
> > formalizing of those rules, as well as by use of more than one sort
> > of formalization (when formality is required).  What would be wrong
> > with completely abstracting sanity checking?  It's common practice.
> 
> I don't understand what you mean by "completely abstracting sanity
> checking".  Is (or is not) "sanity checking" validation against some
> model? 

Sanity checking can be dealt with in a variety of locations.  For three
examples:  when a message is received; when it's generated; when the code
to generate it is designed.

Clearly different systems have different requirements there.  Some systems
can't trust their messaging partners to generate correct data.  Some have
more control, and strong enough design practice that they can "abstract
sanity checking" out of the runtime environment completely.


> 	 The thing you seem to be objecting to
> here is the idea that we should always be able to tell what the shape
> of a hole is, so we can shape our pegs accordingly, and know in
> advance whether the messages we're sending will be understandable in
> precisely the ways we intend them to be understood by those who
> receive them.

Not at all.  I'm just saying there are different ways to discover
the shape of the hole (as it were :-) and having the document declare
such things is far from the only way.

You can look at this from the communications-theoretic point of view
if you like:  information that's already known doesn't need to be
redundantly encoded in each message.  Leads to improved efficiency in
data transmission as well as in data processing.  That knowledge is an
attribute of the overall communication, NOT just individual messages.

- Dave

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

• References:
  • RE: Another look at namespaces
    • From: MURATA Makoto <murata.makoto@f...>
  • Re: Another look at namespaces
    • From: "Steven R. Newcomb" <srn@t...>
  • Re: Another look at namespaces
    • From: David Brownell <david-b@p...>
  • Re: Another look at namespaces
    • From: "Steven R. Newcomb" <srn@t...>

• Prev by Date: Re: RFC: Attributes and XML-RPC
• Next by Date: Re: Summaries please! (RE: We gotta break up these digests)
• Previous by thread: Re: Another look at namespaces
• Next by thread: Re: Another look at namespaces
• Index(es):
  • Date
  • Thread