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

TimBL,

I want to further understand the rationale for this chain of reasoning.  My
comments do not indicate support, they are for my clarification only.

I tried to think about how software would work to do this, and what
motivated step #5.

I imagine the flow from a client software perspective is:

1. Recieve XML document with a specified namespace name.
2. Software processes XML document and finds namespace name.
3. Software decides to retrieve document at namespace name for more
information.  This could be a Schema, Relax, RDF Schema, XLink, whatever.
The software does not know the type of namespace name document before-hand
(we don't have end-resource typed URIs - though this is an incredibly common
usage model).
4. Software then uses both source XML document and namespace document in an
application specific manner.

In understanding this from the RDF Schema perspective, I also came up with
some questions and assumptions:
0. The usage from an RDF Schema perspective is generally around expanding
the information wrt to the document - effectively a modularity issue.
Otherwise I expect that the XML document would actually contain the RDF
information.
1. Can an RDF document refer to another RDF document for content/modularity?
If so, should the software follow all the "inclusions" or just one level?
2. How does the software know what the "type" of namespace name document is?
There's been some discussion on conneg, but this doesn't seem clear to me
for the general case.  What if my software doesn't understand RDF Schema?
3. Is the namespace name document cachable?  Say I had an often used RDF
Schema document, does it have a "time to live" or somesuch?  Is there anyway
of "invalidating" the cache of namespace name documents?  I'm imagining the
obvious case of what happens when the namespace name document changes state.
4. How is security handled wrt RDF Schema documents?  Presumably the
namespace name document server doesn't dish out namespace name RDF Schema
documents that contain useful information (like employee information) to
just anybody that asks.  Or is the model that the RDF Schema information is
roughly the same security level as XML Schema, that is generally publicly
available?  Obviously this is related to question #6, 8, 9.
5. If the software wants to but doesn't understand the namespace name
document, is this an error or not?  Say it's an RDF Schema, does that mean
that the software can't proceed?  I assume the software can proceed without
the RDF Schema document.
6. The RDF information in the namespace name document is applicable to every
instance of that document.  Further that this information is fairly
"static", like an XML Schema or a DTD.  I reached this assumption because of
the discussions where XML Schema containing RDF Schema seemd to be of strong
interest to you.
7. Even if the document is always available, is the software REQUIRED to
process the namespace name document?  In many WSDL/XML Schema scenarios, the
schema validation is not done at runtime - rather the optimized software
code validates the instance document.
8. Could the namespace name document be a dynamic document?  One of the
interesting use cases I've chatting with folks about is the use of namespace
name documents for registry information.
9. If the namespace name document is dynamic, how or would additional info
 query params?) be passed in?  As in, get me the namespace name document
tailored for David Orchard.
10. If the namespace name document is NOT dynamic, is there a model that the
static namespace name document supplies some kind of assertions and
references to the dynamic content?
11. Is there any kind of control given to the client software over the
contents namespace name document, kind of like browsers controlling the
content they want render?  I'm thinking of a client wanting to "prune" the
tree of info that is used after all the assertions have been retrieved.

I thank in advance for the responses.

Cheers,
Dave




> -----Original Message-----
> From: www-tag-request@w3.org
> [mailto:www-tag-request@w3.org]On Behalf Of
> Tim Berners-Lee
> Sent: Thursday, February 28, 2002 12:55 AM
> To: Jonathan Borden; Simon St.Laurent; TAG
> Subject: Re: [namespaceDocument-8] 14 Theses, take 2
>
>
> Some of the following seem to me self-evident:
>
> 1.  We cannot now define the languages which will be
> available later to say
> things about namespaces.
>
> 2. Human readable information is good.  Humans can sue it
>
> 3. Machine-readable information is good.  It allows automatic
> processing.
>
> 4.  Where there is machine-readable information, it must be
> machine-accessible from the namespace URI, either directly or
> indirectly,
> but without human intervention.
>
> 5. Where all the information available can be expressed in
> one (not too
> long) document then an indirection for the sake of it is an
> engineering
> mistake.  So clients should be prepared to accept information
> directly or
> indirectly, ideally.
>
> Now less self-evident but none the less pretty evident:
>
> 6. Where content negotiation is used, it should only be used
> to negotiate
> between documents which really are equivalent - they
> basically say the same
> thing in a different language.  For example, it would not be
> appropriate to
> give and RDF schema and XML schema for a namespace because they really
> contain different information, and a machine or human would
> be fooled into
> thinking it knew the import of a document, when really it had
> been given
> something different.
>
>
>
> ----- Original Message -----
> From: "Jonathan Borden" <jonathan@openhealth.org>
> To: "Simon St.Laurent" <simonstl@simonstl.com>; "TAG" <www-tag@w3.org>
> Sent: Wednesday, February 20, 2002 4:26 PM
> Subject: Re: [namespaceDocument-8] 14 Theses, take 2
>
>
> > Simon St.Laurent wrote:
> >
> > >
> > > > 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?
> > >
> > > Preserving diversity at that stage in processing seems
> like a wise idea
> > > to me.  Indirection preserves choice by readers.
> Recommending that as
> > > best practice to authors seems to be more than
> "indirection just for the
> > > sake of it".
>
> Indirection doesn't preserve choice when there is only one choice.
> When >1 document is available, then you can put an indirection in.
> It is reasonable to change the definitive information about a langauge
> because you get better at writing definitive information,
> even when the
> language has not changed.  (E.g., it is reasonable to add a
> xml schema for
> namespaces defined before sxmlschema was available; it is reasonable
> to add Web ontology information to an RDF schema which
> existed before the
> web ontology vocabulary, and so on)
>
> > I strongly agree that indirection should be promoted as a
> best practice.
> >
> > >From the point of view of efficiency, it doesn't matter either way:
>
> In what way?  An indirection costs time, and having to understand two
> langauges adds complexity.
>
> [...]
> > Jonathan
>
> Tim
>
>

Received on Monday, 4 March 2002 10:24:12 UTC