Forwarded message 1
Jonathan, and colleagues on the XML Core WG!
Long ago -- longer ago than I like to think, but 24 January 2002, to
be exact -- Jonathan sent a comment to the XML Schema WG, with a CC to
the XML Core WGs (as well as to XML Query and XSL, whom I have dropped
From the CC list, for now), on the subject of schema infoset fix-ups.
http://lists.w3.org/Archives/Member/w3c-xml-schema-wg/2002Jan/0090.html
In that note, Jonathan, you raise three issues. These have, after
various detours through the different forms in which the XML Schema
Working Group has endeavored to maintain its issues lists, landed in
Bugzilla as the issues pointed to below.
Issue 1: namespace fixup when a namespace-qualified attribute is
defaulted:
2102 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=2102)
for 1.0; closed long ago (when? don't know) as LATER, i.e.
to be fixed in 1.1.
2105 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=2105)
for 1.1; closed today as FIXED
2830 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=2830)
for 1.1; unintentional duplicate of 2105;
closed today as FIXED
Issue 2: namespace fixup when a value of type QName is defaulted.
2103 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=2103)
for 1.0; closed long ago as LATER (defer to 1.1)
2748 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=2748)
for 1.1; closed today as WONTFIX
Issue 3: reflection of legacy types specified in schema in infoset
4159 (http://www.w3.org/Bugs/Public/show_bug.cgi?id=4159)
for both versions (at least for now); not yet closed
This note is to let you know (both you, Jonathan, as the individual
originator of these issues, and the XML Core WG, as an interested
party as maintainer of both the basic Infoset spec and of XInclude)
that the XML Schema Working Group has today approved a wording
proposal which addresses both issue 2105 and issue 2748, and to ask if
you are content with the disposition of those issues.
In summary, part of the proposal deals with the case of a defaulted
attribute with a non-absent target namespace; for such attributes the
proposal:
* Adds a namespace attribute if needed, to declare a prefix for
the target namespace of a defaulted attribute.
* Requires that [in-scope namespaces] be updated if needed, to
include a mapping for the target namespace of a defaulted
attribute.
* Adjusts the prefix on the attribute as needed for consistency
with the (possibly modified) [in-scope namespaces].
* Leaves ·implementation-dependent· whether
o The [in-scope namespaces] on dependents is updated for
consistency.
or
o Further namespace attributes are added on children for
consistency with their [in-scope namesapces].
Note that the second of these is allowed only when the
implementation supports Namespaces 1.1.
* Adds a note pointing out that when dependents are adjusted,
the option of adjusting their [namespace attributes] property
instead of their [in-scope namespaces] property is allowed only
when the implementation supports version 1.1 of Namespaces.
Another part of the proposal makes explicit that it is
implementation-dependent whether namespace fix-up is performed for
default values of type QName. The following note, added after the
summary of infoset contributions for elements, gives the flavor:
Note: When clause 5.1 of Element Locally Valid (Element) (§3.3.4)
above applies and the {value} applied is of type QName or
NOTATION, it is implementation-dependent whether namespace fixup
occurs; if it does not, the prefix used in the lexical
representation (in [normalized value] or [schema normalized
value]) will not necessarily map to the namespace name of the
value (in [schema actual value]).
The WG did not achieve unanimity on all details here; some WG members
initially wished to make namespace fixup for defaulted QNames be
required, or failing that implementation-defined (meaning that
implementations are required to document their behavior), but there
was consensus only for weaker proposal that they be allowed to perform
namespace fixup, with no further obligations.
Since the resolution of bug 2105 does require namespace fixup of
conforming processors, as you suggested, it has been marked FIXED.
Since the resolution of bug 2748 does NOT require fixup, I've marked
it WONTFIX, although I think the clarification is worth something.
Bugzilla doesn't seem to have a keyword for HALF-FIXED.
Issue 4159 remains open.
The full details of the new wording, intermingled with numerous other
changes (sorry), may be found in
http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.f2f0701-
amendments.200702.html
(W3C member-only link).
As the originator of these issues, Jonathan, we ask you to signal your
agreement with (or at least: acquiescence in) these decisions by going
into Bugzilla and marking the issues CLOSED. Or you can indicate your
dissatisfaction with the decision by changing the status to REOPENED.
If that doesn't work, please reply to this email (including the
comments list, or the XML Schema IG, on the addressee or CC list). If
we don't hear from you in a couple of weeks, we'll assume you
acquiesce and the issues will be marked CLOSED.
As an interested party in the matter, the XML Core WG is similarly
invited to indicate your degree of satisfaction (or resignation) on
the topic.
Thank you.
--C. M. Sperberg-McQueen
for the XML Schema WG