[Bug 11005] First note in 3.16.6.3 Type Derivation OK (simple)

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11005

Dave Peterson <davep@iit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davep@iit.edu

--- Comment #1 from Dave Peterson <davep@iit.edu> 2010-10-11 04:09:36 UTC ---
(In reply to comment #0)

> (a) the indentation of the Note is curious. It is different from the
> indentation of the immediately following notes, which suggests, I think
> wrongly, that it is relevant only to the final clause of the constraint Type
> Derivation OK (simple).

I'm not prepared to comment on whether the Note *should* only apply to 2.2.4.3,
but it is certainly coded in the source XML as being part of that clause; the
other three Notes are not.

> (b) I'm not sure that in the case of the lexical mapping, the Note is actually
> true. Given a base type B defined as union(xs:string, xs:date), and the derived
> type D defined as xs:date, then the lexical mapping for D includes the mapping
> from 2010-10-10 to an xs:date, which is not present in the lexical mapping for
> B (because that string maps to a value in the value space of xs:string).

But it is in the mapping, because of Section 2.3.  See following.

> (However, I'm having considerable trouble interpreting section 2.3 here. On the
> one hand, it states that the lexical mapping for the type union(string, date)
> is not a function, since the same string is the lexical representation of
> values in both member types. On the other hand, the section says "Should a
> derivation be made using a derivation mechanism that removes ·lexical
> representations· from the·lexical space· to the extent that one or more values
> cease to have any ·lexical representation·, then those values are dropped from
> the ·value space·.", which, if it applieas to union(string, date) would seem to
> suggest that all dates are removed from the value space and therefore from the
> lexical mapping; it's hard to reconcile these two statements.)

No.  The whole point is that the lexical representations of dates in
union(string,date) are mapped both to strings and to dates.  From 2.4.1: 
"[Definition:]  Union datatypes are (a) those whose ·value spaces·, ·lexical
spaces·, and ·lexical mappings· are the union of the ·value spaces·, ·lexical
spaces·, and ·lexical mappings· of one or more other datatypes, which are the
·member types· of the union, or (b) those derived by ·facet-based restriction·
of another union datatype."  Mappings are intended to be sets of ordered pairs.
 Thus, a union cannot remove any ordered pairs from the mapping, hence cannot
remove any strings/values from the lexical or value spaces.  The "derivation
mechanism that removes lexical representations" rule that you mention refers to
facets such as pattern which directly remove lexical representations.

It is true that if a date representation is encountered where your union
applies, the representation will be associated with the string value (barring
no other influence, such as an xsi:type attribute).  This is not because the
other value has been removed, but because of the ramifications of 2.4.1.3
(q.v., especially the first few paragraphs and the definition of "active basic
member").

As a matter of history, as best I can remember, this business of non-function
lexical mappings was introduced to ensure that there was no magic involved whe
xsi:type attributes were presentl.  If, e.g. in your union(string,date), an
xsi:type attribute specified date, there needs to be a lexical mapping pair
available that maps to a date.

Hope this helps.  (And I hope I haven't missed anything--it's getting late.  
;-)  )

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 11 October 2010 04:09:40 UTC