W3C home > Mailing lists > Public > xml-names-editor@w3.org > August 2000

Re: Determining attribute uniqueness seems to require namespace prefix in Infoset

From: Joseph M. Reagle Jr. <reagle@w3.org>
Date: Fri, 11 Aug 2000 14:07:11 -0400
Message-Id: <>
To: Dan Connolly <connolly@w3.org>
Cc: John Boyer <jboyer@PureEdge.com>, xml-names-editor@w3.org, www-xml-infoset-comments@w3.org, XML DSig <w3c-ietf-xmldsig@w3.org>
At 12:24 8/11/2000 -0500, Dan Connolly wrote:
 >    Mar. 8, 2000: Namespace Myths Exploded by Ronald Bourret 

"Fortunately, the resolution of this myth is unimportant, as it does not
affect how documents that use XML namespaces are written or how
namespace-aware applications process unprefixed attribute names."

So my question is the above true? This thread started when Gregor [1]
commented we need to go through our examples and interop instances and
qualify the attributes as required by the namespace spec. However, the
namespace doesn't require this (but it also states that those attributes are
not qualified). However, we can still be schema valid because our schema
uses attributeFormDefault="unqualified". However, I'm not sure of what all
the implications of this choice are which leads to the STATUS comment in the
Signature spec:

        1. Ensure that our use of schema namespaces and qualifications
        provides a single schema that can be used for enveloped 
        signatures (signature within content being signed), enveloping 
        signatures (content is within signature being signed) and detached
        signatures (over data external to the signature document).

If someone that understands namespaces and attributeFormDefault better than
me could make a recommendation about which path we should pursue, I'd
certainly appreciate it!

[1] http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/2000JulSep/0240.html

Joseph Reagle Jr.   
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/People/Reagle/
Received on Friday, 11 August 2000 14:07:14 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:24 UTC