Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Web Design Principles (was Re: Generality ofHTT
 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@p...] 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... 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
