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 1803 - [FS] editorial: E.1.4.1 Simply erases
Summary: [FS] editorial: E.1.4.1 Simply erases
Status: ASSIGNED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Last Call drafts
Hardware: All All
: P2 minor
Target Milestone: ---
Assignee: Michael Dyck
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-07-22 04:02 UTC by Michael Dyck
Modified: 2007-11-04 06:00 UTC (History)
0 users

See Also:


Attachments

Description Michael Dyck 2005-07-22 04:02:12 UTC
E.1.4.1 Simply erases

Notation / rule 1 / judgment_form_declaration 1
"statEnv |- SimpleValue simply erases to String"
    It seems like statEnv isn't needed for these judgments.

Sem / rule 2
"statEnv |- SimpleValue1 simply erases to String1 SimpleValue1 != ()"
    This is formatted like one premise, but it's actually two.
    (Ditto the line after it.)
(leftover from last year, comment #263)

Sem / rule 3 / conclusion
"AtomicValue of type AtomicTypeName"
    This is ungrammatical.
    s/AtomicValue/AtomicValueContent/g
    An AtomicTypeName is not a TypeName.
(leftover from last year, comment #264)

Sem / rule 3 / conclusion
"simply erases to dm:string-value(AtomicValue) of type xdt:untypedAtomic"
    But this doesn't conform to the judgment form declaration:
        ... simply erases to String
Comment 1 Jerome Simeon 2006-02-21 19:41:29 UTC
#1 Notation / rule 1 / judgment_form_declaration 1. Removed statEnv from those
judgments.

#2 Sem / rule 2. // Fixed.

#3 Sem / rule 3 / conclusion. // Fixed AtomicValueContent. An AtomicTypeName is
a QName which is a TypeName for an atomic type, so I think this is ok.

#4 Sem / rule 3 / conclusion // Removed of type xdt:untypedAtomic.

- Jerome
Comment 2 Michael Dyck 2006-04-13 04:21:13 UTC
(In reply to comment #1)
> 
> #3 Sem / rule 3 / conclusion. // An AtomicTypeName is
> a QName which is a TypeName for an atomic type, so I think this is ok.

TypeName does not derive AtomicTypeName, so TypeAnnotation cannot derive "of type AtomicTypeName".

Comment 3 Jerome Simeon 2006-04-13 16:04:30 UTC
As in #1804, I really do not see where the problem is. The values represented by AtomicTypeName are a subset of the values represented by TypeName.
- Jerome