Re: Bring back src? (was Re: simple question on namespaces.)
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format