OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   Re: Another look at namespaces

[ Lists Home | Date Index | Thread Index ]
  • From: "Steven R. Newcomb" <srn@techno.com>
  • To: xml-dev@ic.ac.uk
  • Date: Mon, 20 Sep 1999 23:19:46 -0500

[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.
If you're saying that I think that strict adherence to models is
essential for reliable, vendor-independent processing of interchanged
information, then you're exactly right: I do "conflate reliable
information interchange with schemas".

> 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?  If it isn't, I'm completely baffled.  If it is, are you saying
that the model should not be formalized, to protect machines from any
possibility that they will be used to perform the sanity check?  Or
are you saying that there should be nothing rigorous about the model;
that "sanity" is something that only a human being can judge,
impressionistically, in the same manner as "beauty"?

> I'd really not want to see W3C create a world of square
> pegs, given the wide variety of hole shapes (triangular, elliptical,
> heptagonal, etc) in use, and the fact that many problems don't fit
> well into the hole/peg class of design models!  ;-)

I agree with you that everyone should be able to make holes and pegs
in whatever shapes they want.  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.  In the case of any two people who want to interchange
information, I see no advantage in either of them being unable to tell
whether a message will be interpretable on arrival.  Please explain
the nature of this advantage.

-Steve

--
Steven R. Newcomb, President, TechnoTeacher, Inc.
srn@techno.com  http://www.techno.com  ftp.techno.com

voice: +1 972 231 4098
fax    +1 972 994 0087
pager (150 characters max): srn-page@techno.com

3615 Tanner Lane
Richardson, Texas 75082-2618 USA

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@ic.ac.uk
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@ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@ic.ac.uk)






 

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS