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

 


Help: OASIS Mailing Lists Help | MarkMail Help

 


 

   RE: [xml-dev] Web Design Principles (was Re: [xml-dev] Generality ofHTT

[ Lists Home | Date Index | Thread Index ]

It will come back to the question of what tells me what is in 
the message.  If I am doing business with several customers 
or suppliers, I actually want to know who sent it before 
I find out which It it Is because we have multiple types 
of It.  I might want to look up 
which Public ID we are to be working with, and oh, have 
they ever in the past sent anything else when they said This 
was That It.  Tit For Tat: Negotiation 101 (trust but verify 
on last default).

1. Well-formedness.  We could have waffled on the Draconian 
Parse, but it was considered a must-have.  Otherwise, it 
simplified things.  Making something simple in one place 
usually makes something complicated elsewhere (conservation 
of complexity:  Universe Design Principles ;-) ).  In this 
case, if I enable well-formedness, I either trust or don't 
care.  Past behavior is the basis for ontological commitment. 

2.  Validity.  According to what or whom?  Most serious 
professionals know that validation is a requirement for 
some cases and other than choosing the means, it becomes 
the organization's job by policy to decide when and if 
to validate.  SGML says, always.  XML says, it's up to 
you.  That means the answer to "who do you trust" gets 
answered every time you negotiate implicitly or explicitly.

If you just want the computers to decide, you leave it 
to SGML.  If you want humans in the loop, XML does that. 

You have to decide where the liberal features are to be 
implemented.  The web architecture is not the most powerful 
distributed computing system ever devised.  It is in many 
ways, weak and a throwback to the days when people were 
cheap and computers were expensive.  Now that those 
positions are reversed, the architect needs a lot of 
flexibility to tailor the implementation to the local 
requirements (competence, available expertise, time 
in the day, rate of traffic, criticality of transaction, 
and so on).  The web manages this by weakening constraints 
for applying contraints (essentially, statelessness, 
well-formedness, subsets of standards in specs).
  
Insofar as we can say "the web" is real, we have to 
also say, "it is not all there is on the Internet and 
you may want to choose a different set of components 
to use in your implementation".  Then it becomes a lot 
harder than HTML.  Address unification is done on the 
Internet not by URIs but by the DNS.  The map above 
that which HTTP negotiates is just component-based 
logic.  Nothing real or required, but extremely 
convenient.

If addresss unification via URIs is all there is to 
the web, the W3C and TAG's jobs became obsolete quite 
a while back and mission creep has definitely set in. 
I don't think a URI is all there is to it, but I think
the architectures being debated don't either.

There ain't no "The Web".  Just parts and assemblies.

len

-----Original Message-----
From: Paul Prescod [mailto:paul@prescod.net]

Also, I notice that some people make a distinction between
well-formedness and validity when it comes to this issue. Aren't they
the same? Couldn't we say that if a purchase order comes through that is
not well-formed it should be routed to a human being who looks for the
missing angle-bracket and inserts it? It isn't a job I want to have but
if you're serious about being liberal in what you accept...




 

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

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