xml-dev - Re: Bring back src? (was Re: simple question on namespaces.)

[Dan Brickley <Daniel.Brickley@bristol.ac.uk>]

On Fri, 29 Dec 2000, Simon St.Laurent wrote:

> At 06:56 PM 12/29/00 +0000, Dan Brickley wrote:
> >...whatever. Point being that 'src' (FWIW I prefer 'seeAlso') is just a
> >(rather boring) bit of meta-information about the namespace whose
> >identifier is 'http://example.com/xmlns/myvocab', and that there are
> >many other things one might want to say about that NS without having to
> >burden one's instance data with that info.
> 
> seeAlso would do fine - the point would simply be that there _should_ be
> something retrievable at that location, independent of whether or not the
> namespace URI can be resolved to some resource body.  It would take a huge
> philosophical load off the back of namespace identifiers, and might be
> worth the small extra burden imposed on the instance data.  I don't see any
> way to accomplish that without infrastructure which doesn't exist today
> (DDDS, etc.) or without establishing a 'meaning' involving dereferencing
> namespace URIs.

Yep, given the hype around XML, SOAP/XP etc., I don't reckon it'll be
long before we see folk queue up to offer services that expose these kinds of
annotations on namespaces. I can live with 'src' in instance data,
though I expect it to become rather easy to find that information
through other means. 

eg. I expect to be able to do something rather like...	

	SELECT 	?location, ?ownerkey 
	FROM    http://xmlxmlxmlxml.example.com/xmlnslookup?ns=urn:foo:myvocab
	WHERE 	(util::seeAlso urn:foo:myvocab ?location)
		(util::publisherPubKeyFingerprint urn:foo:myvocab ?ownerkey)
	USING util FOR http://example.com/ns-description-vocab 

...in an SQL-ish RDF query language, returning:

	location = http://MYVocab.example.org/ 
	ownerkey = FA0C 0D5A 2B3F 808D AA28 2B63 3E15 EF2F 7322 8FE4 

...and then head off to http://MYVocab.example.org/ in the expectation
of finding _something_ when I dereference.

Since there'll only be so many public namespaces, the job of running a
namespace description service is nothing like that of running a general
search engine (and there are plenty of the latter around). 

Anyhow the interesting piece of work that needs doing is that of
defining the seeAlso (or src) relation, including clear expectations
about status of what one might find when dereferencing. 


> Maybe it's time to accept worse is better so that we can get on with real
> work instead of looking over our backs all the time.
> 
> >Or maybe we could better argue about the properties of namespaces
> >(seeAlso, publisher etc), rather than about the places in
> >XML documents where we expect to find that information...
> 
> If you're actually looking forward to the next 20,000 messages on what
> namespace URIs mean, it might be a fun argument.  

Ugh, not my cup of tea I'm afraid. I tried to follow the whole xml-uri
discussion but tuned out when it turned into the URNs-URLs-URLs debate
all over again.

> The only people I think are looking forward to the argument are those who
> expect to win it, and I'd suggest that any expectation of 'winning' in this
> situation is delusional at best. 

I'm looking forward to avoiding 20,000 message-long threads wherever
possible in the new year. In this case I reckon you've got the right
idea for avoiding endless discussion: provide meta-information about
namespaces. My only concern is that your proposal to do this using a
magic xmlnssrc:foo construct sounds like a lot of work. If you broke the
proposal down into two parts (what we want to know about a ns; how and
where to write that down in xml) you might be onto a winner. eg a lot of
people might agree about the usefulness of src/seeAlso, and build useful
tools/services, without being persuaded that we need to use xmlnssrc
attributes to represent that information...

dan