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 5896 - Description of particles and terms in 2.2.3.2 confusing
Summary: Description of particles and terms in 2.2.3.2 confusing
Status: CLOSED LATER
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: editorial
Depends on:
Blocks:
 
Reported: 2008-07-24 09:44 UTC by Pete Cordell
Modified: 2010-11-10 17:32 UTC (History)
1 user (show)

See Also:


Attachments

Description Pete Cordell 2008-07-24 09:44:32 UTC
In 2.2.3.2 I find the description of particles, terms and their relationship 
confusing.  (I also wanted to remove the word "term" that appears in "term 
in the grammar" because the section talks about "term" later, and it seems 
best to avoid having the same word mean different things in a similar 
context.)

I originally posted a comment to the comments mailing list, to which Michael Sperberg-McQueen added some clarification (http://lists.w3.org/Archives/Public/www-xml-schema-comments/2008JulSep/0071.html).

Based on those comments I'd therefore like to suggest the following re-wording:

A particle is a concept in the grammar used to describe element content.  A particle consists of either an element declaration, a wildcard or a model group.  A particle also consists of occurrence constraints. Particles contribute to validation as part of complex type definition validation, when they allow anywhere from zero to many element information items or sequences thereof, depending on their contents and occurrence constraints.

A [Definition:] Term is either an element declaration, a wildcard or a model group (i.e. any of the three kinds of component that can appear in a particle).  A particle has (among others) a property called {term} which is a Term.  As such the {term} property is either an element declaration, a wildcard or a model group, and the content of the {term} property is often referred to as the "Term" of the particle.  All Terms are themselves Annotated Components. [Definition:]  A basic term is an Element Declaration or a Wildcard. [Definition:]  A basic particle is a Particle whose Term is a basic term.

Thanks.
Comment 1 David Ezell 2009-07-24 16:06:20 UTC
The WG, with regret, has decided that it's too hard to reengineer these terms at this point.  
Comment 2 Pete Cordell 2009-07-24 17:00:52 UTC
Here's another attempt:

------------------

A [Definition:]  Term is either an element declaration, a wildcard or a model group. All ·Terms· are themselves ·Annotated Components·. [Definition:]  A basic term is an Element Declaration or a Wildcard. 

A particle is a concept in the grammar for element content, consisting of a Term, together with occurrence constraints. Particles contribute to ·validation· as part of complex type definition ·validation·, when they allow anywhere from zero to many element information items or sequences thereof, depending on their contents and occurrence constraints.

[Definition:]  A basic particle is a Particle whose {term} is a ·basic term·.

-----------------

Also, should particles have a definitions?  i.e. should the second sentence start as:

A [Definition:] particle is a concept in the grammar 
Comment 3 Pete Cordell 2009-07-25 08:42:56 UTC
Thinking about this some more, I'm not sure whether a particle is a synonym in the grammar for 'element content' or whether particles are the entities that are used to describe element content.  I've adopted thelatter in the revised attempt below:

------------------

A [Definition:]  Term is either an element declaration, a wildcard or a model
group. All ·Terms· are themselves ·Annotated Components·. [Definition:]  A
basic term is an Element Declaration or a Wildcard. 

A [Definition:] particle consists of a Term, together with occurrence constraints.  Particles describe element content.  Particles contribute to
·validation· as part of complex type definition ·validation·, when they allow
anywhere from zero to many element information items or sequences thereof,
depending on their contents and occurrence constraints.

[Definition:]  A basic particle is a Particle whose {term} is a ·basic term·.

Comment 4 Dave Peterson 2009-07-25 14:52:00 UTC
(In reply to comment #3)
> Thinking about this some more, I'm not sure whether a particle is a synonym in
> the grammar for 'element content' or whether particles are the entities that
> are used to describe element content.

Particles are components of a particular kind.  So the latter is the better interpretation.
Comment 5 Dave Peterson 2009-07-26 15:21:11 UTC
(All this speaking for myself, not in any way for the Schema WG.)

I believe that you'll find that the component structure and names of kinds of components follow the following rule:  The largest "kind" of component is "any kind of component".  There are sub-kinds of components, such as "annotated components" and "term[ componen]ts".  At the bottom of the "kind" hierarchy are the (seventeen, I believe) kinds of components explicitly described in chapter 3:  "attribute declaration[ component]s", "model group definition[ component]s", "particle[ component]s", etc.  I believe that the bottom-of-the-hierarchy kinds of components do not have definitions marked as such, whereas the other kinds (which are unions of these b-o-t-h kinds) do have formally marked definitions.

At least a quick but not exhaustive search leads me to that conclusion.  If I'm right, then it would probably seem odd to make a definition for one of the b-o-t-h kinds but not the others.

I suspect that your confusion over the two uses of the word "term" would be lessened if the occurrences that are links to the component kind were visually distinct from those that are referring to words in our technical English jargon.  (And that all such occurrences were marked as such, if there are some that aren't.

Whew!

N.B.:  I use the word "kind" rather than "type" or "class", because some people associate both those latter words with object-oriented concepts; OO is in turn associated with "data hiding", and XML is in their minds just the opposite :  making data more visible.  So OO terminology becomes anathema in this context.
Comment 6 Pete Cordell 2009-07-27 13:55:33 UTC
Thanks Dave.  This has been illuminating to me.  The idea that 'kind' is a special word in the vocabulary of the spec has been lost on me up until now.  For example, where the spec says 'kinds of', such as in:

    The name [Definition:]  Component covers all the different kinds of 
    schema component defined in this specification.

I hadn't concluded that 'kind' had a special meaning and had assumed that the sentence could equally have been written as:

    The name [Definition:]  Component covers all the different sorts of 
    schema component defined in this specification.

Or:

    The name [Definition:]  Component covers all the different forms of 
    schema component defined in this specification.

This has led to some confusion when I read things like:

    Schema Component: Attribute Declaration, a kind of Annotated Component

To which I ask, is it or isn't it an Annotated Component then?!  i.e. I read it as:

    Schema Component: Attribute Declaration, sort of like an Annotated Component
    but not really!

At first I thought the best way to address the confusion would be to Define .Kind. in section 2.2, and then reference this definition in the various headings, such as:

    Schema Component: Attribute Declaration, a .kind. of Annotated Component

But maybe it's just better to get rid of kind from the headings, e.g. do:

   Schema Component: Attribute Declaration - an Annotated Component
   Schema Component: Element Declaration - a Term
Comment 7 David Ezell 2010-11-10 17:32:00 UTC
The WG reported this bug as LATER on 2009-07-27.  We are closing this bug
as requiring no futher work.  If there are issues remaining, you can reopen
this bug and enter a comment to indicate the problem.  Thanks very much for the
feedback.