[
Lists Home |
Date Index |
Thread Index
]
>I've been thinking about the kind of processing I do with XML.
>
>Nearly all of it involves matching against patterns. Some of it
>involves simple less-than/greater-than work with position.
I can't see any reason for less-than/greater-than to have a role in the
definition of URIs - this surely has to be left to the end user (agent). We
might for example want to sort the URIs as strings alphabetically or by the
profit made by the URI's owner, not something appropriate for any standard.
>I think the largest concrete problem I have with URIs is their lack of a
>common mechanism for saying this equals that. I can live without
>ordering for names, so that's not a big deal, but the lack of clarity on
>things like:
>
>HTTP://MONASTICXML.COM
>
>vs.
>
>http://monasticxml.com
>
>vs.
>
>http://monasticXML.com
>
>is pretty much killing, even without issues of relative and absolute,
>query strings, etc. I don't see this getting better in the near future,
>as IRI issues and questions about escaping appear to be growing, not
>resolving.
This most certainly *is* an issue.
For my due centissimi I'd suggest that for pragmatic reasons, the
equivalence should be determined by the scheme used in the URI, so if http
says http://monasticxml.com == http://monasticXML.com then these two URIs
should be considered equivalent. If in Homer's scheme homer:beer !=
homer:BEER then as URIs they should be considered different. This would
apply in cases where the schema's idea of equivalence might not be what we'd
expect - e.g. homer:beer == homer:morebeer
I doubt whether relative URIs would have any use.
It would probably be easiest to include a default case-insensitivity rule,
so that http://homer == HTTP://homer etc.
>The lack of clarity - heck, the outright refusal to acknowledge the
>question - about how to get from an identifier to a resource or back
>again - is the nails in the coffin.
This is IMHO a non-question - an identifier has no other role than
identifying, getting to and from resources lies outside of the scope. (We
have a cat called 'Sassi', this name is of no use whatsoever at retrieving
the resource).
>It seems on the face of it to be a poor match for a system which depends
>at its foundations on identifying and recognizing labels.
I agree in respect to the comparable point.
>Maybe it's time to ask if "SGML for the Web" is getting poisoned by some
>folks' notion of the Web, even while it succeeds regularly in expanding
>(often questionably) in expanding many people's concrete experience and
>understanding of the Web.
Personally I think that "SGML for the Web" and similar approaches (I don't
think I'd get away with calling the Semantic Web "AI for the Web", but you
know what I mean) are probably harmful, because it's putting a round peg in
a square hole - it might fit, but there's a lot of gaps. Better I reckon to
lose the baggage and take a rather Maoist Specification-Zero approach.
Cheers,
Danny.
|
