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 3736 - canonical mappings should be presented uniformly
Summary: canonical mappings should be presented uniformly
Status: CLOSED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard: thimble, work
Keywords: decided
Depends on:
Blocks:
 
Reported: 2006-09-18 12:51 UTC by Dave Peterson
Modified: 2006-10-14 03:18 UTC (History)
0 users

See Also:


Attachments

Description Dave Peterson 2006-09-18 12:51:53 UTC
There are only two primitive datatypes whose description includes a separate subsection for the canonical representation mappings:  decimal and hexBinary.  Neither of them seem substantive enough to warrant a separate subsection.  Each should be moved into the preceding subsection on Lexical Mapping, as is the case for the other primitive datatypes.  This effectively simply removes the subsection headings from these two subsections.  (The separate subsections are inherited from 1.0, and have been removed from all the other primitive datatype descriptions.)
Comment 1 C. M. Sperberg-McQueen 2006-10-09 20:18:02 UTC
I've never seen the purpose of eliminating the separate subsections, but
given that we have done so for all the rest of the primitive types
we might as well do so for these last two.

While we are tweaking this bit of the document, we should probably take
the opportunity to change the name of the second subsection on each
primitive type (3.3.n.2) from 'Lexical Mapping' to the more informative
and suggestive 'Lexical representation'.
Comment 2 Dave Peterson 2006-10-09 20:29:04 UTC
(In reply to comment #1)

> While we are tweaking this bit of the document, we should probably take
> the opportunity to change the name of the second subsection on each
> primitive type (3.3.n.2) from 'Lexical Mapping' to the more informative
> and suggestive 'Lexical representation'.

Well, I always thought 'Lexical Representation' was less informative; I guess YMMV applies.  Of course, in 1.0 (where we used 'Lexical representation'), we never gave the lexical mappings, so we never said which "lexical representations" represented which values.  Which biased me against the phrase as a title.
Comment 3 Noah Mendelsohn 2006-10-09 22:10:26 UTC
> > While we are tweaking this bit of the document,
> > we should probably take the opportunity to
> > change the name of the second subsection on each
> > primitive type (3.3.n.2) from 'Lexical Mapping'
> > to the more informative and suggestive 'Lexical
> > representation'.

> Well, I always thought 'Lexical Representation'
> was less informative; I guess YMMV applies.  Of
> course, in 1.0 (where we used 'Lexical
> representation'), we never gave the lexical
> mappings, so we never said which "lexical
> representations" represented which values.  Which
> biased me against the phrase as a title.


The term "lexical representation" is widely used in Schema 1.0 part 2.  While I have no strong preference on the question discussed above, I think it's essential that we continue to provide a compatible definition for that term.  So, we can either stick with "lexical representation", or we can go with "lexical mapping" but explain that references in external specifications to the "lexical representation" of a type should be understood as referring to the lexical mapping in the case where schema 1.1 is used.

In short, my concern is that external specifications may refer to the term "lexical representation", and I don't want those specs to break or require extensive revision when they move to Schema 1.1.

Noah
Comment 4 Dave Peterson 2006-10-10 00:22:45 UTC
(In reply to comment #3)

> The term "lexical representation" is widely used in Schema 1.0 part 2.  While I
> have no strong preference on the question discussed above, I think it's
> essential that we continue to provide a compatible definition for that term. 
> So, we can either stick with "lexical representation", or we can go with
> "lexical mapping" but explain that references in external specifications to the
> "lexical representation" of a type should be understood as referring to the
> lexical mapping in the case where schema 1.1 is used.
> 
> In short, my concern is that external specifications may refer to the term
> "lexical representation", and I don't want those specs to break or require
> extensive revision when they move to Schema 1.1.

If you find the definition of "lexical mapping" in Schema 1.1 (Section  2.3) you will find the definition of "lexical space" and "lexical representation [of]" immediately following.  I believe that the "lexical representation" definition is consistent with the undefined 1.0 term "lexical representation".  In 1.0 we never did explain how lexical representations were mapped to values.  Or if we did, I can't find it now.

Hence, fear not.  We are puting the specs that refer to Schema datatype lexical representations onto an even firmer footing than they were with only 1.0 to rely on.
Comment 5 Noah Mendelsohn 2006-10-10 01:35:59 UTC
Sounds good.  I should have checked for a definition of lexical representation in the 1.1 draft before writing.  Thanks for the clarification.
Comment 6 Dave Peterson 2006-10-14 02:53:02 UTC
The WG has decided to remove the canonical mapping subsections and place their contents at the end of the preceding lexical mapping subsections, but decided not to change the title of the lexical mapping subsection.
Comment 7 Dave Peterson 2006-10-14 03:18:04 UTC
The changes have been made in the status quo document.

Since I introduced the bug, I hereby accept the result and mark the issue closed.