URIs as IDs in ModSAX (was Re: ModSAX (SAX 1.1) Proposal) (fwd)

Robb Shecter shecter at darmstadt.gmd.de
Thu Feb 18 12:00:53 GMT 1999


Dan Brickley wrote:

> On Wed, 17 Feb 1999, I wrote:
>
> > ("Don't assume there's anything at this 'not-URL' ").  From a software engineering point of
> view...
>
> (I'd argue that software engineers who write code that assumes all URLs
> can be unproblematically de-referenced are asking for trouble. but
> that's besides the point)
>

Yes, but I'm not assuming that the users / app. programmers / clients of these standards are
"software engineers".  I'm assuming that we are, though. :)  I think that the truly successul and
universal systems are those that can be used by biologists, teachers, linguists, etc.
Mathematically or abstractly, HTML, Perl and CGI are not beautiful creations, but they are
understandable and consistent in the right ways.  And they are -still- regretfully, the standard
for www applications and documents.

I guess that a basic problem I have is that seeing something like:

http://a.b.c/d/e

that doesn't reference a retrievable resource is misleading and confusing because of the
"http://".  Why are we saying how to retrieve this thing that cannot be retrieved?  Millions of
people in the world now understand that this prefix speficies how to get something.  Now we want to
say that that's not quite true; it's an "abstraction".  In some cases.  I don't think that will
work.  I don't think people will get it, or have time or want to get it.

To me this is a design question:  Buttons on UI's should look "actionable" and text labels should
not.  Doors in buildings should not have handles on the inside when people are required to push to
open them.  etc.

> > - Instead of saying, "Watch out for the problem here...", we should not create the problem in
> > the first place.
>
> We are not creating a problem. It is fine to use a URL to identify a SAX
> property, but by choosing to allow _all_ forms of URI we leave room for
> other approaches. This echoes the approach taken by XML namespaces.
>

Yes, and I think that namespaces is confusing.  Maybe I haven't studied it rigorously enough.  And,
after reading about Dublin Core, and its use of a trailing "#" on the namespace value, I'm confused
more.  Especially seeing at least one site that doesn't do this. ( http://dmoz.org/rdf.html )

> > I think that the Java standard is very good. I don't think that it's unfriendly towards
> > non-Java implementations:  it is after all, only a standard, and not hardcoded into the
> > language.
>
> I disagree. The string 'util.tools.png' is as meaningless in the Java
> community as in the wider world...

I may or may not agree, but I don't see how the Java standard is unfriendly towards other
languages.  For example, there's no special language feature for parsing strings with dots as
tokens.

- Robb


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)




More information about the Xml-dev mailing list