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