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 1365 - a mechanism for replacing character strings with markup would be useful
Summary: a mechanism for replacing character strings with markup would be useful
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 1.0 (show other bugs)
Version: Last Call drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Ashok Malhotra
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
Depends on:
Reported: 2005-05-11 04:59 UTC by Felix Sasaki
Modified: 2005-09-29 10:58 UTC (History)
0 users

See Also:


Description Felix Sasaki 2005-05-11 04:59:11 UTC Comment ID: 14
Comment 1 Michael Kay 2005-05-11 08:41:58 UTC
I think you are referring either to xsl:analyze-string in XSLT, or to character
maps, also in XSLT.

"Markup" is a serialization concept rather than a data model concept. We have
taken the view that all facilities for constructing new nodes belong in the XSLT
and XQuery languages rather than in the function library. This is because in
most cases they require custom syntax, as they are too complex to express using
function calls alone.

Michael Kay (personal response).
Comment 2 Felix Sasaki 2005-05-25 06:35:13 UTC
(consensus of i18n-core-wg, telecon 25 may 2005):

We agree that "Markup" is a serialization concept and that facilities for
constructing new nodes belong in the XSLT and XQuery languages rather than in
the function library. In your reply to the original comment you mentioned
character maps and analyze-string from XSLT. It seems that you could achive our
goals, i.e avoiding the private use area, by s.t. like

<xsl:template match="text()">
 <xsl:analyze-string select="." regex="\x{E001}">
   <myChar type="E001"/>

Input: <p>bla&#xE001;bli</p>
Output: <p>bla<myChar type="E001"/>bli</p>

Is this true? Is there a similar facility in XQuery? It would be great to have
this example as an example in the XSLT 2.0 spec, of course marked as example
(with <div class="example">...). As you mentione elsewhere, examples do not
belong to the normative part of a spec, but - especially in the case of XSLT 2.0
- they make it easier to adopt a standard within wider communities.
Comment 3 Michael Kay 2005-05-25 15:31:47 UTC
The regular expression should be written


and I think you would want an <xsl:non-matching-substring> element to copy other
characters across unchanged; but apart from those details the example is OK.

I'm not sure that including this example in the XSLT spec would add much value;
it's basically a simplified version of one of the other examples that's already
there, except for the use of a regex that matches PUA characters. I'll take
guidance from my colleagues on this.

In XQuery I think this particular example is achieved most easily without using
regular expressions at all, rather using a recursive function such as

declare function expandPUAChar($string as xs:string, $char as xs:string) as
item()* {
  if (contains($string, $char))
  then (substring-before($string, $char),
        <myChar code="{string-to-codepoints($char)}",
        expandPUAChar(substring-after($string, $char), $char))
  else $string

Michael Kay
Comment 4 Michael Kay 2005-06-14 13:43:06 UTC
Extract from XSL WG minutes of 9 June 2005:

Anders - only works for element content and not for attributes.
  Sharon - Do they want us to put this example in XQuery or F&O ?
  Anders - addtional comment #2 - want to do this instead of using private
           use area.
  M. Kay - valid example, but why?  Adding to the XSLT spec doesn't
           add much value (see comment #3).
  Sharon - why is this pushed back to us?  comment #3 seems like the
           right answer.
  Norm   - works for him.
  M. Kay - example is slightly wrong but ok in spirit.

  Action: Sharon will send Michael's comment #3 to XQuery WG - still
pending as of 4:57 on Friday 19 [should read 9] June 2005
Comment 5 Jim Melton 2005-06-29 16:49:26 UTC
The XML Query WG has discussed this comment and the dialog recorded herein. 
After a bit of explanation that helped members of the WG to understand the
meaning of the comment, the WG concluded that the situation is both sufficiently
uncommon and sufficiently similar to existing examples that no changes to the
specifications are required or desirable, not even the addition of an example. 
Therefore, the WG has determined to resolve this comment with no change to the

We appreciate your feedback on the XML Query specifications. Please let us know
if this response is satisfactory. If not, please respond to this message,
explaining your concerns.  If you find the response satisfactory, please mark
the comment CLOSED. 

Jim Melton
On behalf of the XML Query Working Group