[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Namespace related-resource bundles: just the one?

• From: Miles Sabin <MSabin@i...>
• To: xml-dev@l...
• Date: Mon, 01 Jan 2001 17:40:03 +0000

Uche Ogbuji wrote,
> Miles Sabin wrote,
> > As a consequence it looks as though we wouldn't be able to 
> > take an _existing_ document instance (which already 
> > references a resource bundle via it's namespace URI) and, for 
> > example, associate it with a different XML or RDF schema 
> > without negotiating with the controllers of the existing 
> > bundle URI.
>
> Good point.  I see this as an implementation issue once one of 
> the Namespace Catalogue specs gets adopted.  I would suggest 
> good old processing instructions (remember those?)
>
> <foo xmlns="http://spam.com">
>   <?namepace-resolution-redirect from="http://spam.com" 
> to="http://myorg.com"?>
>   <bar/>
> </foo>

Where would this fragement live tho'? Not in the resource at the
end of the namespace URI, for the reasons already given; and not
in the document instance (tho' we could generate a new doc with
the fragment prepended; but then we might as well map into a new
namespace).

> Again, I think that the existing proposals govern the remote 
> data format, and that this should be separated from 
> implementation within processors. For instance, here are a 
> couple of my current implementation ideas.

Yes and no. The problem's not so much with the catalog proposals,
but with the linking mechanism. A namespace has precisely one
identifier == URI, so under the current schemes it can be
associated with no more than one bundle of related resources
(modulo content negotiation etc.). That doesn't seem to leave
an awful lot of room for manoeuvre.

All the current proposals set up the following dependencies,

  Doc instance -> catalog -> XML schema
                          -> RDF schema

so, if we can't modify either the doc or the catalog we can't 
change the doc-schema association. Maybe instead we need 
something more like,

 Bundle1 -> doc instance -> default catalog -> default XML schema
                                            -> default RDF schema
         -> user XML schema 1
         -> user RDF schema 1
 
 Bundle2 -> doc instance -> ... as above ...
         -> user XML schema 2
         -> user RDF schema 2

 etc.

along with rules governing how related resources specified at the
bundle level override (or may not override) resources at the 
default catalog level. Using this sort of scheme we can change 
associations without having to touch either the document instance 
or the default catalog.

In fact, we might not even need a default catalog at all, we
could simply let that be one more bundle along with all the
others,

 Default bundle
         -> doc instance
         -> default XML schema
         -> default RDF schema

 Bundle1 -> doc instance
         -> user XML schema 1
         -> user RDF schema 1
 
 Bundle2 -> doc instance
         -> user XML schema 2
         -> user RDF schema 2

In which case we wouldn't even need to think about dereferencing
any namespace URIs.

Hmm ... didn't any of this get addressed by the (now defunct)
packaging activity?

Cheers,


Miles

-- 
Miles Sabin                               InterX
Internet Systems Architect                5/6 Glenthorne Mews
+44 (0)20 8817 4030                       London, W6 0LJ, England
msabin@i...                         http://www.interx.com/

• Follow-Ups:
  • XML Namespace Catalog proposal 2nd edition
    • From: Jonathan Borden <jborden@m...>

• Prev by Date: Re: Namespace related-resource bundles: just the one?
• Next by Date: XML Display in IE5/Netscape - Urgent
• Previous by thread: RE: Namespace related-resource bundles: just the one?
• Next by thread: XML Namespace Catalog proposal 2nd edition
• Index(es):
  • Date
  • Thread