OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Namespace Basic Principles

> Anyway, your question is what an SW processor would do -- somehow, it
> would find a schema for each Namespace (I seem to recall that XML
> Schemas provided an attribute for that purpose) and then would
> download the four schemas referred to by that schema, then the four
> schemas referred to by each of those, etc., until the ninth or tenth
> level when the system broke down trying to download and parse 4^10 or
> so schemas to try to interpret a single XML document.  Of course,
> that's assuming that none of the schemas was unavailable or
> maliciously altered because of security breaches at any one of the
> hundreds of different hosts being accessed.

Yeah right, just like a SW search engine would download every page from
the Web onto your desktop, convert it into an RDF representation of the XML
Infoset, and load it into a Prolog system to service your queries while
you wait. Maybe that's why SW fans have been asleep for 10 years? ;-)

You're both right (contrariwise, you're both wrong). What Dan describes is
pretty much what search engines do today: they download the web in
presentation form and scrape it out into  indices. It's dumb as anything,
but it seems to make some kind of business sense. To my knowledge they don't
use much XML or Prolog, which is their loss of course :). On the other hand
I can easily imagine David's scenario: first generations of metadata engines
doing precisely the same thing  driven by schemas or whatnot, except they'll
be scraping indices into indices. 

To quote someone who knew a bit about metadata:

"I saw that one enquiry only gave occasion to another, that book 
referred to book, that to search was not always to find, and to 
find was not always to be informed."

Sam Johnson said that in 1753. We're still nowhere really.


Bill de hÓra  :  InterX  :  bdehora@interx.com