W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > November 2005

Re: meeting record: 2005-11-15 HTML TF telecon

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Tue, 22 Nov 2005 11:10:54 -0500
To: "Ralph R. Swick" <swick@w3.org>
Cc: public-rdf-in-xhtml-tf@w3.org
Message-ID: <87iruk8xyp.fsf@nwalsh.com>
/ "Ralph R. Swick" <swick@w3.org> was heard to say:
|    Mark: Norm's biggest objection was that there might be two meanings to
|    a given abc:def pattern; one interpreted using namespaces and one not.
|    But I point out that this ambiguity already exists and in practice is
|    resolved in context. 

Where does it already exist and how is it resolved using a context
other than the in-scope namespaces?

|    Mark: the issue may only be that RDF/XML uses the term "QName" too
|    often. I described this in mail: "[9]RE: CURIEs vs. QNames". I believe
|    that CURIE can continue to use ':' without ambiguity, just as is done
|    in XPath

In XPath, tokens of the form

  NCName ":" NCName

*are* QNames. The binding for the prefix comes from the in-scope
namespaces and it is an error to use a prefix which is not bound.

|    Ralph: so if there is no actual ambiguity, I would argue that it
|    increases the learning curve for users to have different syntaxes for
|    QName and Abbreviated URI

I still don't see how there could possibly *not* be ambiguity. Can
someone show me an example where the element "x:y" contains a CURIE of
the form "x:y" and demonstrate that there isn't ambiguity?

Assuming it can be done, I still think overloading the ":" is going to
be more confusing to users rather than less confusing.

                                        Be seeing you,

Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

Received on Tuesday, 22 November 2005 16:21:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:50:19 UTC