Re: Summary of the QName to URI Mapping Problem

i'm confused.
mostly by how people are able to completely dismiss patrick's concerns.

he is completely on target.

maybe he just isn't stating his case in terms y'all can understand.
perhaps a paraphrase will help. (apologies to patrick if i misparaphrase)

QName -> URI mappping is broken because

1) 
	possibility of URI collsion.
	
	person a maintains namespace 'urn:abc' and has a property defined
	in that space called 'xyz'.
	person b maintains namespace 'urn:ab' and has a property defined
	in that space called 'cxyz'.

	so, when each gets serialized to 'XML', they look something like
	this, respectively:
	abc:xyz
	ab:cxyz
	
	and this becomes a problem when the RDF processor does it's concat
	maneuver and gets two identical URIs for two different properties.

	this really looks like a problem to me. 
	if it's not, someone will have to explain why it isn't.

2)
	URI scheme where concat doesn't make sense.
	
	person a maintains namespace urn:abc(foo).
	names within the space are formed like urn:abc(foo(bar)).
	
	now, there are two possibilities for QName construction here.
	either we seperate the name from the namespace and get
	'xmlns:foo=urn:abc(foo)' and 'foo:bar'
	or we just cut off some random suffix and get something like
	'xmlns:foo=urn:abc(foo(' and 'foo:bar))'

	now, the latter allows, theoretically, for correct URI reconstruction,
	but i don't think too many XML parsers i going to like it.

	and the former is accepted by parsers, but doesn't allow for correct
	URI reconstruction, because urn:abc(foo)bar is not the correct URI.

	again, this seems like a problem. 
	sure, the spec implicitly says that properties have to be of the
	kind that allow for the concat maneuver, but a) that kind of
	restriction seems like a bad idea in the long term, and b) should
	be stated explicitly if that's the intention.

again, i apologize if i've misrepresented what patrick has said.
i hope this helps, but doubt it will.

devon smith
smithde@oclc.org