This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 7096 - clarifications needed for annotation mapping?
Summary: clarifications needed for annotation mapping?
Status: CLOSED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: Macintosh Mac System 9.x
: P2 normal
Target Milestone: ---
Assignee: David Ezell
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2009-07-10 21:52 UTC by C. M. Sperberg-McQueen
Modified: 2009-10-10 20:44 UTC (History)
1 user (show)

See Also:


Attachments

Description C. M. Sperberg-McQueen 2009-07-10 21:52:57 UTC
Reading the description of annotation mappings today, I
find myself uncertain about a couple aspects of this
design.

1 The first clause of the definition contains a note
reading:

    Note: As described above (earlier in this section),
    the {attributes} property of each Annotation
    component includes any attribute information items
    on the parent (and possibly ancestors) of the
    <annotation> element which have a [namespace name]
    different from the XSD namespace.

Reading this, I find myself asking "and possibly
ancestors? How am I to know whether ancestors are
included or not?"  I believe the answer is given in the
XML mapping tableau, which says that non-XSD attributes
are copied from the annotation element itself, from the
source-declaration element which maps to the component,
and from any intervening elements.  We could say that
again here and make the note read:

    Note: As noted above, the {attributes} property of
    each Annotation component includes all the
    attribute information items on the annotation
    element itself, on the XML element which represents
    (and maps to) the component being annotated, and on
    any intervening XML elements, if those attribute
    information items have [namespace names] different
    from the XSD namespace.

2 The second clause of the definition of annotation
mapping says that if there are any other non-XSD
attributes on any element E in the set of elements
being mapped, there will be an annotation component
with empty {application information} and empty {user
information}, which will carry the relevant attributes
from E.[attributes].

Consider the example 

 <xsd:complexType name="T23" my:color="green">
  <xsd:complexContent my:stone="diamond">
   <xsd:extension base="B:T23" my:dow="Tuesday">
    <xsd:sequence>
     <xsd:element ref="A:other"/>
    </xsd:sequence>
   </xsd:extension>
  </xsd:complexContent>
 </xsd:complexType>

Does the definition of annotation mapping mean that
there will be three annotation components on type T23,
A1, A2, and A3, with

  A1.{attributes} = { my:color='green' }
  A2.{attributes} = { my:stone='diamond' } 
  A3.{attributes} = { my:dow='Tuesday' }

Or will there be a single annotation component, with

  {attributes} = { my:color='green',
                   my:stone='diamond', 
                   my:dow='Tuesday' }

?  Clause 2 says

    2 If there are any attribute information items
      among the [attributes] of any element information
      item E in ES with a [namespace name] different
      from the XSD namespace, which are not included in
      the {attributes} of any Annotation from clause 1,
      then there is an Annotation component in AS whose
      {application information} and {user information}
      are the empty sequence and whose {attributes}
      contains all and only such attribute information
      items among E.[attributes].

The words "then there is an Annotation component in AS
...  whose {attributes} contains" the otherwise
homeless attributes would seem to suggest there should
be one annotation.  

The words "whose {attributes} contains all and only
such attribute information items among E.[attributes]",
on the other hand, suggest to this reader a different
annotation compnent for each E in the element set which
carries non-XSD attributes.

The answer will matter for a SCDs test which asks for

  /type::T23/annotation[2]

Trying to find wording less susceptible to
misunderstanding, I suggest the following two
alternatives for consideration:

Plan A:  

    2 If any element item E in ES has any attribute
      information items A such that all of the following
      are true:

        2.1 A is in E.[attributes] 
        2.2 A.[namespace name] is present and not the
            XSD namespace
        2.3 A is not included in the {attributes} property
            of any annotation component described in
            clause 1

      then for each such E, an Annotation component C
      will appear in AS, with C.{application
      information} and C.{user information} being the
      empty sequence and C.{attributes} containing all
      and only those attribute information items A
      among E.[attributes].


Plan B:  

    2 If any element items E in ES have any attribute
      information items A such that all of the following
      are true:

        2.1 A is in E.[attributes] for some E in ES
        2.2 A.[namespace name] is present and not the
            XSD namespace
        2.3 A is not included in the {attributes} property
            of any annotation component described in
            clause 1

      then one Annotation component C will appear in
      AS, with C.{application information} and C.{user
      information} being the empty sequence and
      C.{attributes} containing all and only those
      attribute information items A.  

         Note:  if the attribute information items in
         C.{attributes} originate on different elements
         in ES, they are not guaranteed to have
         distinct names.
Comment 1 David Ezell 2009-07-24 16:39:07 UTC
SG to report on what Xerces does.  
Comment 2 Sandy Gao 2009-08-07 15:53:01 UTC
For issue #2, I think plan A was the intention, that is, "for each E ..., there is an Annotation for E".

For issue #1, I agree the new note is clearer.
Comment 3 C. M. Sperberg-McQueen 2009-08-07 15:55:47 UTC
At its call of 7 August, the WG agreed to adopt the note in item 1 of the description, and adopt Plan A in item 2.    Editors to integrate into new status quo document.
Comment 4 C. M. Sperberg-McQueen 2009-10-10 20:44:14 UTC
This change is now in the status quo document; this issue can be marked resolved.