Re: [namespaceDocument-8] 14 Theses, take 2

At 04:55 PM 18/02/02 -0600, Dan Connolly wrote:

>> Finally, Dan Connolly had an issue with Thesis 13 "Namespace
>> documents should not favor the needs of any one application or
>> application class" which I never got time to understand. Dan?
>
>Whatever you put there is going to favor the needs of some
>applications over others. For example,
>  12. Namespace documents should be human-readable.
>favors the human-browsing application over, say, validation stuff.

Yup, I'll accept that.  I'm explicitly arguing that explaining 
namespaces to humans is of special importance among all the other
things you might want to do with them - because that's how you
empower people to do things with them.  I agree that there's a
contradiction in my theses unless I better highlight this
prejudice.

>TimBL made the point that if the only definitive material
>I have about my namespace is, say, an XML Schema, why
>not use that as a namespace document? i.e. why use
>indirection just for the sake of it?

Because I just have trouble believing in an interesting
namespace whose only definitive material is an XML Schema;
or any other kind of schema, using "schema" in the syntax-
constraint sense.  Can we have some examples please?

It seems to me like you're arguing about what to do in a 
scenario that is just really unlikely to arise.

And I would further argue that if all you had was an XML
Schema, you would still be better off using as a namespace
document something that explained this was a surprising
and unusual kind of namespace for which the only material
is an XML Schema, go get it *here*; because when someone
else improves the namespace by adding more definitive
material you'll have a place to put a pointer to that.

>Thesis 13 (and 14) seems to say that it's necessary to pick
>one data format for all namespace documents. Not so;
>to each his own. And if my namespace is pretty special-purpose,
>what's wrong with using a special-purpose data format
>to document it?

I don't know about the first sentence.  If you give me
human-readability and indirection as architectural principles,
it's reasonable to have an argument about how best to achieve
that.  The problem with special-purpose data formats as
definitive material is that it makes it less likely that
other people will go out and write software to do cool stuff
with your special-purpose data.  Which pretty well 
flies in the face of the web architecture as I see it.

>I'm not interested in debating
>
>  12. Namespace documents should be human-readable.
>
>independent of a principle that
>
>  Documents should be human-readable.

Well, I am.  It's hard to see how SVG and MathML and RDF and
X3D can be made usefully human-readable.  We're not allowed
to talk about whether namespace docs should be human-readable
until we have solutions in place for the whole spectrum of
languages?  I am arguing precisely that namespace documents
have an unusually strong requirement for human readability. -Tim

Received on Tuesday, 19 February 2002 00:00:31 UTC