an unfilled need

[David LeBlanc]

I should like to point out, with all due respect, that there is no software
anywhere written to date in the world that "knows" the meaning of anything.
I don't think anthromorphization serves any useful purpose here.

David, I think your example is a bit strained here. Recognition of a
citation doesn't seem to me to be materially different from recognition of
<toollist>.

As in all human communication (which includes XML or HTML no matter it's
bias towards easy computer recognition of content), I think there's an
assumed common referent for things like pliars and citations and such. Any
marked departure from such common referents reduces the ability to
communicate imho.

I don't think any markup language is, or has the potential to be, a
universal language. It does offer the opportunity, within a community of
interest, for people to agree on the meaning and structure of information
that's relevant to that domain and for people who become interested in that
domain to rapidly become fluent in the vocabulary of that domain.

I don't think it's appropriate for any single organization to attempt to
set definitions (i.e. specify namespaces) for particular domains of
interest. I see that as an exercise best left to those who know whatever
particular domain they are creating a tagset/namespaces for.

Sincerely,

Dave LeBlanc

At 05:25 PM 9/5/99 -0400, David Megginson wrote:
>Ann Navarro writes:
>
> [on Namespaces]
>
> > That need is: a formal deterministic means of discovery. 
>
>Discovery of what?  Structural rules are easy enough, but they buy you
>almost nothing -- after all, if you give me an arbitrary piece of XML
>with a DTD, my software can tell you whether it's valid or not, but
>not what it means.
>
> [snip]
>
> > The "rest of the world", is looking for a means of discovering what
> > belongs with that name, it's associated definitions, semantics, and
> > other data that may be necessary to complete their operations.
>
>I cannot imagine how we could accomplish this, without simply mapping
>to an artificially restricted set of a-priori meanings.
>
>For example, for displaying HTML in a browser all the meaning you need
>is a collection of flow objects ("block text", "link", "graphic",
>etc.), but what kind of schema language or other discovery mechanism
>could allow software automatically to determine the meaning of
>
>  <irony>Have a nice day!</irony>
>
>or
>
>  <task>
>   <tools-required>
>    <tool>spanner</tool>
>    <tool>needle-nosed pliers</tool>
>   <tools-required>
>   <steps>
>    <step>loosen the main bolt with the spanner</step>
>    <step>pull out the blue wire with the needle-nosed pliers</step>
>   </step>
>  </task>
>
>?
>
>My point is that it's a pointless task, at least without access to
>much more advanced artificial intelligence than is currently
>available.  
>
>In the mean time, though, it is entirely possible to write software
>that *does* know what it's looking for, such as a search engine that
>knows that HTML <cite> can hold a book title, or a Newsroom system
>that knows that XMLNews <subject-name> holds a description of one of
>the subjects of a News story.  Namespaces are valuable precisely
>because they allow software to find markup that it knows about and to
>do something useful with it.
>
>While the Utopian vision of software that can figure out how to deal
>with what it *doesn't* know about is enticing, we're so far away from
>any practical implementation right now (except, again, for
>artificially-restricted subsets) that standardizing would be a waste
>of time.  
>
>That's not to say that there's no point in standardizing some of those
>tiny subsets by providing facilities for linking to structural schemas
>and stylesheets, but it does mean that structural schemas and
>stylesheets provide don't solve the problem of what markup means -- so
>far, and for the forseeable future, that knowledge is hard-coded in
>the software itself at some level.
>
>
>All the best,
>
>
>David
>
>-- 
>David Megginson                 david at megginson.com
>           http://www.megginson.com/
>
>xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
>Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on
CD-ROM/ISBN 981-02-3594-1
>To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
>(un)subscribe xml-dev
>To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
>subscribe xml-dev-digest
>List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)
>
>

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)