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 6722 - Definition of laxly assessed is not clear
Summary: Definition of laxly assessed is not clear
Status: CLOSED FIXED
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: David Ezell
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2009-03-20 16:07 UTC by David Ezell
Modified: 2010-11-10 17:43 UTC (History)
1 user (show)

See Also:


Attachments

Description David Ezell 2009-03-20 16:07:23 UTC
At the telcon the WG approved the following wording in dispensation bug 5412.  
However, the WG wanted to open a new bug against the following wording:

[Definition:]   If the item cannot be ¡¤strictly assessed¡¤, because neither clause 1.1 nor clause 1.2 above is satisfied¡ü or the necessary components are missing (see Missing Sub-components (¡ì5.3)¡ü, and the item is not ¡¤skipped¡¤, the element information item's schema validity must be laxly assessed by ¡¤validating¡¤ with respect to ¡¤xs:anyType¡¤ as per Element Locally Valid (Type) (¡ì3.3.4.4) and assessing schema-validity of its [attributes] and [children] as per clause 2 and clause 3 above. If the element information item is ¡¤skipped¡¤, it must not be laxly assessed.
Comment 1 David Ezell 2009-07-24 16:18:39 UTC
SG:  concern is that in this definition for lax assessment, we also say >when< it happens.  We should separate the conditions out.
MSM:  how can a definition of term, have the verb "must be".
MSM:  I suggest in a paragraph either before or after, insert a new defintion for "laxly assessed" and strip the definition markup from the statement in question.
MSM: strict and lax are not complements (with regard to <xs:any/>).
Comment 2 C. M. Sperberg-McQueen 2009-07-24 22:52:13 UTC
The minutes of 20 March provide a little more detail about what
we thought was odd about the current formulation; I reproduce the
relevant words here for the record:

    Looking at definition of laxly accessed: definition is very
    odd in that it appears to mostly be about when you MUST to
    lax accessment; the definitional aspects are a little lost.

The current text of section 3.3.4.6 Schema-Validity Assessment
(Element) includes the following paragraph within the text of the
Validation Rule: Schema-Validity Assessment (Element),
immediately following the numbered list of clauses which defines
the term 'strictly assessed'.

    [Definition:] If the item cannot be ·strictly assessed·,
    because neither clause 1.1 nor clause 1.2 above is satisfied
    or the necessary components are missing (see Missing
    Sub-components (§5.3), and the item is not ·skipped·, the
    element information item's schema validity must be laxly
    assessed by ·validating· with respect to ·xs:anyType· as per
    Element Locally Valid (Type) (§3.3.4.4) and assessing
    schema-validity of its [attributes] and [children] as per
    clause 2 and clause 3 above. If the element information item
    is ·skipped·, it must not be laxly assessed.

Following up from this morning's discussion, I propose here two
possible resolutions of the issue.  

Plan A: 

A1) First, replace the paragraph just quoted in full with:

    If an item cannot be ·strictly assessed·, because neither
    clause 1.1 nor clause 1.2 above is satisfied or the necessary
    components are missing (see Missing Sub-components (§5.3),
    and the item is not ·skipped·, the element information item's
    schema validity must be laxly assessed.  If the element
    information item is ·skipped·, it must not be laxly assessed.

The new text is mostly the same as the old with these changes:

  - s/the item/an item/ in the opening words of the paragraph.

  - Remove the markup which identifies the text of the 
    current paragraph as a definition.

  - Delete the words "by ·validating· with respect to
    ·xs:anyType· as per Element Locally Valid (Type) (§3.3.4.4)
    and assessing schema-validity of its [attributes] and
    [children] as per clause 2 and clause 3 above" from the
    first paragraph.

A2) Second, after the validation rule Schema-Validity Assessment
(Element), insert a paragraph defining the term 'laxly assessed'
and a note:

    [Definition:] The schema validity of an element information
    item E is laxly assessed if and only if both of the following
    are true:

      1 E has neither a ·governing element declaration· nor a
        ·governing type definition·.

      2 E is ·validated· with respect to ·xs:anyType· as
        defined Element Locally Valid (Type) (§3.3.4.4) and the
        schema-validity of E's [attributes] and [children] is
        assessed as described in clause 2 and clause 3 of
        Schema-Validity Assessment (Element) (§3.3.4.6).

      Note: It follows from the definitions given that no element
      information item can be both ·strictly assessed· and ·laxly
      assessed· in the same schema-validity ·assessment· episode.


Plan B: 

B1) First, replace the validation rule with something like:

    Validation Rule: Schema-Validity Assessment (Element)

    The schema-validity assessment of an element information item
    E is performed as follows:

      1 If E has a governing element declaration or a governing
        type definition, then E MUST be strictly assessed.
      2 If E is skipped, E MUST NOT be assessed.
      3 Otherwise, E MUST be laxly assessed.

B2) Second, follow this new formulation of the validation rule
with the definitions of strict and lax assessment, so they would
not be textually part of the validation rule itself.  

B3) Change the introductory wording of 'strictly assessed' from

    For the schema-validity of an element information item E to
    be strictly assessed, all of the following must be true:

to 

    An element information item E is strictly assessed if and
    only if, all of the following are true:

B4) Take the definition of lax assessment and the following
note from Plan A.

B5) Optionally change both definitions to begin not with

    An element information item E is strictly | laxly assessed if
    and only if ...

but instead with

    An element information item E is said to be strictly | laxly
    assessed if and only if ...


Discussion

I think Plan B is better spec drafting; it separates the
definitions of terms more cleanly from normative requirements on
processes and processors.

On the other hand, if the WG prefers Plan A (as I expect some
members of the WG will), I can live with it.
Comment 3 David Ezell 2009-09-04 16:18:33 UTC
The WG approve Plan B on the telcon
Comment 4 C. M. Sperberg-McQueen 2009-10-09 22:58:12 UTC
The change approved on 4 September is in the status quo document, so I'm marking the issue resolved.

for the record I'll also note that after the status quo document of 4 September was generated, the change adopted started to cause layout issues; I do not understand why.   They have now been fixed.  (Keyword in case this ever becomes important to reconstruct:  dummy ID was needed to cause the correct dg local hack to fire.)
Comment 5 David Ezell 2010-11-10 17:43:56 UTC
The WG reported this bug as FIXED on 2009-10-09.  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.