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 6155 - Data Types Should Provide Re-Format Facet
Summary: Data Types Should Provide Re-Format Facet
Status: CLOSED LATER
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Datatypes: XSD Part 2 (show other bugs)
Version: 1.1 only
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-10-12 17:13 UTC by Axel Dahmen
Modified: 2010-03-24 03:52 UTC (History)
2 users (show)

See Also:


Attachments

Description Axel Dahmen 2008-10-12 17:13:11 UTC
Sometimes data in XML is represented using a textual format that differs from the format required by certain datatypes, e. g. xs:datetime.

XML Schema should support a Regular Expression replace facet to re-shape textual representations into a lexical mapping that is understood by built-in data types.


Here's an example:
------------------

The xs:datetime data type requires a datetime to be in the format

"yearFrag '-' monthFrag '-' dayFrag 'T' ((hourFrag ':' minuteFrag ':' secondFrag) | endOfDayFrag) timezoneFrag?"


However, if a datetime value was stored as, e. g. "2008-12-15 13:45"

then there should be a facet available like the following:

  <xs:simpleType name="datetime">
    <xs:restriction base="xs:datetime">
      <xs:reshape
         value="([0-9]{4}-[0-9]{2}-[0-9]{2}) ([0-9]{2}:[0-9]{2})"
         into="$1T$2:00"/>
    </xs:restriction>
  </xs:simpleType>


Axel Dahmen
www.axeldahmen.de
Comment 1 Michael Kay 2008-10-17 15:49:54 UTC
The Working Group looked at this during its meeting on 2008-10-17.

Some members of the WG felt this was a really good idea; however, it is clearly outside the scope of the current work programme for version 1.1.

Therefore we propose to close it with the disposition "Later" which will make it a candidate for including in the requirements for a future release.

If you are content with this resolution, please mark the issue "Closed"; otherwise, please explain with further justification why this needs to be done now.
Comment 2 Axel Dahmen 2008-10-17 23:58:55 UTC
Thank you for your feedback. It would be great to see this in a future release of XML Schema.

One question I have: If I set this bug to CLOSED, won't it lose it's LATER status? How will the LATER status be retained? Or is everything set alright already?

TIA,
Axel Dahmen
Comment 3 Michael Kay 2008-10-18 08:29:17 UTC
The open/closed status of the bug is orthogonal to the resolution. The basic idea as that when a release is finished and the WG starts thinking about the requirements for the next release, the first thing it does is to look at all the Bugzilla entries that were closed with a resolution of "Later".
Comment 4 Axel Dahmen 2008-10-18 12:16:22 UTC
Well, you may think I'm stupid, but the radio button list below this text field box reads "resolution" several times and isn't orthogonal at all. I don't want to make a mistake: How do I actually set the *status* of this bug and not the *resolution*?
Comment 5 Michael Kay 2008-10-23 11:44:36 UTC
I have written a blog entry about this idea at
http://saxonica.blogharbor.com/blog/_archives/2008/10/23/3943494.html

Michael Kay
Comment 6 Axel Dahmen 2008-10-24 08:58:57 UTC
I've just read the blog... Michael, this is GREAT work you've done!

I particularly like the idea of shaping an expression back to it's original lexical space to make XML Schema bijective. That raises the idea to 200 %!

But I tend to believe that XPATH translate() won't provide sufficient functionality. How could it, for example, translate the following date values into valid xs:date values (and back):

  MM.dd.yyyy   (US American)
  dd.MM.yyyy   (German)

I suspect Regular Expression to be a more flexible way to translate arbitrary lexical spaces by identifying and retaining informational part strings.

Examples:

  <!-- (US American date) -->
  <xs:restriction
        shape="/([\d]{2})\.([\d]{2})\.([\d]{4})/$3-$1-$2/"
        reshape="/([\d]{4})-([\d]{2})-([\d]{2})/$2.$3.$1/"
      />

  <!-- (German date) -->
  <xs:restriction
        shape="/([\d]{2})\.([\d]{2})\.([\d]{4})/$3-$2-$1/"
        reshape="/([\d]{4})-([\d]{2})-([\d]{2})/$3.$2.$1/"
      />

Your thoughts?


(I've posted my reply to your blog as well)
Comment 7 Axel Dahmen 2010-03-24 00:06:08 UTC
Whould the time be right to revive this one?
Comment 8 Dave Peterson 2010-03-24 03:52:25 UTC
(In reply to comment #7)
> Whould the time be right to revive this one?

No.  By making the STATUS LATER, the working group is saying that it isn't able (in this case, time-wise, among other things) to consider this now, even though it sounds like an interesting idea that we'd like to see continued.  In point of fact, the working group is trying desperately to get version 1.1 closed out; the only thing we're worrying about are bugs and errors at this point.

Michael Kay said in comment #1:

> Therefore we propose to close it with the disposition "Later" which will make
> it a candidate for including in the requirements for a future release.

Michael is correct; the next iteration of the working group should go through all comments that are marked LATER and consider them.

He then said:

> If you are content with this resolution, please mark the issue "Closed";
> otherwise, please explain with further justification why this needs to be done
> now.

This ultimately lead to your comment #4; it appears that that got lost in the subsequent discussion about regular expressions, and  no one responded to your question.  Let me do so now:

(In reply to comment #4)
> Well, you may think I'm stupid, but the radio button list below this text field
> box reads "resolution" several times and isn't orthogonal at all. I don't want
> to make a mistake: How do I actually set the *status* of this bug and not the
> *resolution*?

Fear not.  Clicking the CLOSE button will "Mark bug as CLOSED" in its STATUS field.  It won't affect the RESOLUTION field.  Right now the STATUS is RESOLVED, the RESOLUTION is LATER.  If you click the CLOSE button, you'll cause the STATUS to change from RESOLVED to CLOSED, the RESOLUTION will remain LATER.

Given that this has been sitting so long, I'm taking the liberty of closing it on your behalf.  I will verify that indeed the RESOLUTION remains LATER.  If this is not satisfactory, please REOPEN the bug.