I thought that some of you who like to stay close to the bleeding edge might like to try out some of the new XSLT 3.0 features implemented in Saxon 9.5.

* xsl:map and xsl:map-entry so you can now construct maps at the XSLT level, not only at the XPath level

--
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell@xxxxxxxxxxxx   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

I thought that some of you who like to stay close to the bleeding edge might like to try out some of the new XSLT 3.0 features implemented in Saxon 9.5.

* xsl:map and xsl:map-entry so you can now construct maps at the XSLT level, not only at the XPath level

--
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell@xxxxxxxxxxxx   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

Dear XSLT Fans,

For people eager to start playing with bleeding edge XSLT 3.0

Relax NG
http://www.sharexml.com/x/get?k=NDGu7yBYGAUC

Relax NG Compact
http://www.sharexml.com/x/get?k=gfC5oPhTcGjx

Best regards,

Xmlizer

Best Regards,
George
--
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com

This information is posted to the XSL-List (and the XSL-List Digest)
at intervals under the subject line "XSL-List guidelines".

INTRODUCTION TO XSL-LIST

XSL-List hosts discussion of XSL itself, XSL applications and implementation,
and XSL user questions. XSL-List is open to everyone, users and developers,
experts and novices alike. There is no restriction to what may be posted on
the XSL-List provided it is related to XSL, which is considered to include
XSLT (versions 1 and 2), XPath (versions 1 and 2) and XSL Formatting Objects
(FO).

XSL-List is not a W3C mailing list, and has no affiliation with W3C (or any
official standing with any standards organization). However, XSL-List was
established with the encouragement of members of the W3C XSL Working Group,
and members of the Working Group are among the subscribers to the list.

Only subscribers can post to XSL-List, but since the goal is to increase the
level of XSL knowledge, XSL-List is being archived for everybody to view. The
topics being discussed on the XSL-List change as new ideas arise or existing
problems are dealt with, but the archive contains all of the ideas and
solutions that have been discussed on the list.

XSL-List is provided by Mulberry Technologies, Inc., as a service to the XSL
user community. Mulberry is an XML and SGML consultancy specializing in
applications that have a text design, processing, interchange, or display
component. For more information about Mulberry Technologies, Inc. see
http://www.mulberrytech.com


SUBSCRIBING TO THE XSL-LIST

To subscribe to the list, fill out the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html.


DAILY DIGEST

Daily digests -- copies of a whole days XSL-List messages sent as one email
message -- are available. Not only is it a single email message containing all
of that day's XSL-List messages, it is also half the size, on average, of the
individual messages since it doesn't include the overhead of the mail headers
from each message.

To unsubscribe from the list and subscribe to the digest, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html.


POSTING GUIDELINES

Only subscribers can post to XSL-List, and only from the exact address they
used when they subscribed.

There is no restriction on what may be posted to the XSL-List provided it is
related to XSL. Items concerning XML but without a direct connection to XSL
should be posted to a XML-related list instead of to the XSL-List. Items
related to DSSSL should be posted to the DSSSList.

Do not begin your subject line with "help" or "subscribe" since the list
software will bounce the message because it looks like is an administrative
request.

It is best to start a new message for a new thread. Do not start a new thread
by replying to an unrelated message and just changing the subject line, since
the header of your message will contain references to the previous message and
your new message will appear in the archive as one of the replies to the
original message.

Both subscribers to the full list (xsl-list@xxxxxxxxxxxxxxxxxxxxxx) and
subscribers to the digest (xsl-list-digest@xxxxxxxxxxxxxxxxxxxxxx) should post
their messages to xsl- list@xxxxxxxxxxxxxxxxxxxxxx; the messages will be
received by both subscribers to the list and subscribers to the digest.


BEFORE YOU POST ... DO YOUR HOMEWORK
- Check that your question isn't already answered in the XSL FAQ at
http://www.dpawson.co.uk/.
- Check that your question isn't already answered in the XSL-List archives at
http://www.biglist.com/lists/xsl-list/archives/.
- If you are asking for help with XSL code, determine which version of the
language you are using (plus extensions, if any), and confirm that your XSL
processor supports that version and/or extension. (If you are unsure of your
processor, this can be determined by using the stylesheet at
http://www.mulberrytech.com/xsl/xsl-list/processor-version.xsl on any input,
including the stylesheet itself: see
http://www.mulberrytech.com/xsl/xsl-list/processor-version.html for more
information.) An XSLT 1.0 engine will not process stylesheets written in XSLT
2.0!


IN YOUR POSTING ...

Name the XSL processor, processor version, and version of the language you are
using. This information is frequently necessary to diagnose a problem exactly,
and always helps respondents give good advice.

If you are replying to a post, trim the quoted message to just the parts to
which you are replying.

In addition to following simple rules of net etiquette and common sense, you
will improve the chances that you will receive prompt and helpful responses
by:
- Asking questions specific enough that answers are possible. Describe what
you are trying to do, how you approached it, what happened, and why you don't
like the result you got. Don't simply say "it gave me an error": paste in the
error message (someone else can probably make sense of it).
-  Illustrating your question with a demonstration of the problem.
Well-composed questions frequently include a small XML sample, an XSLT
stylesheet, the results received, and the result that was desired - all in
miniature, to make it comprehensible to readers new to your problem. (It is
also not uncommon to discover what a problem actually is in the process of
reducing it to an illustrative version.)


USE INFORMATIVE SUBJECT LINES

When posting to the XSL-List, do not use uninformative subject lines like
"Urgent", "Question", or "Newbie HELP!!!", which don't say anything about what
your problem is. Instead, use a meaningful subject line that will make sense
to the people whose help you are trying to get. It may even get a response
from people who normally shy away from "beginner" questions.

Informative subject lines make the XSL-List archive more useful since people
with the same problem will more easily find the relevant threads.


DO NOT CROSS-POST

Cross-posting to the XSL-List and to another list, even XML-Dev or the
DSSSList, is generally counter-productive. No list's archive will contain the
complete thread; cross-posts from non-subscribers continuing the thread will
bounce; and XSL-List subscribers who are not also on the other list will only
see half the thread, as will those on the other list who are not also reading
XSL- List. Subscribers to both lists may see two copies of the message,
annoying them as well.


REPLIES GO TO THE LIST

The reply address of XSL-List messages (and of digests) is
xsl-list@xxxxxxxxxxxxxxxxxxxxxx so REPLIES GO TO THE LIST BY DEFAULT. If you
want to reply to just the author of a post, you should change the "To:" field
in your reply.


USE SHORT QUOTES OF PREVIOUS MESSAGES IN REPLIES

Please do not quote entire messages just to add a few lines at the beginning
or end. Instead, quote the parts to which you are directly replying or quote
enough to establish the context.

Everybody on the list has already received the message that you are quoting,
and anyone searching the archive will find your message and the previous
message listed under the same thread.

Subscribers to the XSL-List will just ignore most of the quoted messages and
move to the next post, but subscribers to the XSL-List Digest will mostly have
to page past the quoted messages to reach the next material in which they are
interested in reading.


POSTINGS MUST BE IN PLAIN TEXT ONLY

Postings to XSL-List must be in plain text only. The XSL-List does not allow
HTML postings because many users cannot display them appropriately, and
because
they are unnecessarily large.


POSTINGS MAY NOT BE IN BASE 64

Postings to XSL-List may not be in Base 64 because it makes a mess of both the
digest and the archive.


ATTACHMENTS ARE BANNED

Since Mulberry's mailing lists have in the past been unwittingly used for
spreading viruses in e-mail attachments, all e-mail attachments are banned
from the XSL-List.

XSL stylesheets are XML files, and XML files are text files, so this does not
affect the majority of posts to the list since you can include the files' text
in the body of your message. If you need to refer to a binary file such as a
PDF file, you should put the file on a Web site or FTP site and include the
file's URL in your XSL-List post.

If you do include an attachment in your XSL-List post -- even a HTML
attachment -- your message will bounce.


YOUR POST WILL BE PERMANENTLY ARCHIVED

Because it is a public resource created by and for the entire XSL
community, we do not edit XSL-List. Therefore, it is responsibility of
list subscribers not to post anything to the list that they do not want
publicly available, possibly for a very long time.

Postings in the list archives will be complete, including: all contents,
examples, sample data, code or code fragments, and email header and footer
contents. An automated process will obscure the domain portion of email
addresses (the part after the @ sign).in the headers and footers of postings,
but no guarnantee is made that this process will be completely successfull.
Other than this, all postings will be archived in public as received.

Further, we at Mulberry could not, even if we wanted to, edit all of the
archives of XSL-List. Several third-parties have created unofficial archives
of
XSL-List, often without asking, or even informing, Mulberry. Postings to
XSL-List
will be included in an unknown and ever-changing variety of web publications.
If
you don't want your questions/comments/answers in public view don't post them
to
XSL-List.


THIRD-PARTY ARCHIVES OF XSL-LIST

Third parties are welcome to create searchable or reference archives of
XSL-List
provided they adhere to the following guidelines:
- the material is clearly labelled as being from XSL-List, with
 an acknowledgement of Mulberry's role as provider of XSL-List
- there is a navigable pointer to the official list page at
 http://www.mulberrytech.com/xsl/xsl-list/ either on every posting
 or associated with the user interface such that it is visible with
 the postings
- list postings are unedited
- either the entire archive of the list is provided or there is a
 clearly stated method for selecting the subset of the list that is provided

Mulberry does not provide these third parties with help to create these
archives, does not endorse particular third party archives, and has no control
over the ways in which they present the material in their systems.

People or organizations that publish the contents of XSL-List without
following
the guidelines above are being very antisocial. Please bookmark either
the official XSL-List archive or one provided by a service that plays nicely
in the community and shun those who do not give credit where credit it due.


UNSUBSCRIBING FROM THE XSL-LIST

To unsubscribe from XSL-List, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html. If you
have difficulties unsubscribing from the list:
 - make sure you are unsubscribing EXACTLY the email address that is
   subscribed
 - if you receive only one message a day from the list be sure to
   check the box marked "Select for the Digest version of the list"
   (if you subscribe to the digest and don't check this box the system
   will try to unsubscribe you from the regular list and fail; it will
   only unsubscribe you from the digest if you check this box.)

UNSUBSCRIBING FROM THE XSL-LIST DIGEST

To unsubscribe from the XSL-List digest, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html and
check the box marked "Select for the Digest version of the list".


IF YOU STOP GETTING XSL-LIST MESSAGES

If you stop receiving XSL-List message, you may have been removed because mail
to you was bouncing. You are not being picked on, and you can just rejoin the
list.


ARCHIVE

XSL-List messages are archived at
http://www.biglist.com/lists/xsl-list/archives/.


REPORTING BUGS IN SOFTWARE

Bugs in software should firstly be reported to its author rather than to the
XSL List. Questions regarding how to work around bugs are welcome, but the
list does not function as a bug-tracking system for any software.


XSL FAQ AND OTHER INFORMATION ON XSL

Dave Pawson's XSL FAQ is at http://www.dpawson.co.uk/xsl/index.html.

The W3C information on XSL is at http://www.w3.org/Style/XSL.

Mulberry's Quick References are at http://www.mulberrytech.com/quickref/ and
cover XSLT, XPath, and XQuery.


DSSSLIST -- THE DSSSL USERS' MAILING LIST

Mulberry Technologies, Inc., also provides the DSSSList -- the DSSSL Users'
Mailing List. For subscription information and the DSSSList archive, see
http://www.mulberrytech.com/dsssl/dssslist.


CONTACT

If you have any questions or problems, please contact
xsl-list-owner@xxxxxxxxxxxxxxxxxxxxxxx


ADMINISTRATIVE COMMUNICATIONS

The list administrator will reply to emailed questions relating to the
mechanics and administration of XSL-List and to help new users learn to use
the list. However, the administrator will not take the time to navigate mazes
of any sort in order to do so. If the list owner's messages are rejected by a
user's anti-spam system the list owner will not pursue the matter. Similarly,
if list-related notices to a subscriber are rejected as spam the subscriber
will be unsubscribed.



CHANGE History

==============
December 26, 2011 - btu.

11. Clarified instructions on unsubscribing from the digest version
    of the list.

==============
May 5, 2009 - btu.

10. Added paragraph clarifying that all content will be archived in
    public, including text, examples, code, and email headers and
    footers including names.

==============
February 1, 2008 - btu.

9. Policy on third-party archives added.

8. Policy banning attachments and postings in Base 64 clarified.

==============
September 1, 2007 - btu.

7. Administrative communication policy clarified.


==============
October 1, 2005 - btu.

6. Mulberry Technologies' relationship to XSL-List clarified. We
   do the work. We pay the bills. Organizations who post unauthorized
   copies of the archive without acknowledging Mulberry's contribution
   are not playing nicely in the community.

==============
March 2, 2005 - btu.

4. Users are asked to identify the version of XSLT and XPath
   they are using for questions that are specific to one version

5. Clarifying the policy on editing the list archive (we don't edit
   it).

==============
March 30, 2004 - btu.

1. All references to subscribing and unsubscribing have been
   updated to reflect changes in the list management system.

2. Pointers to the XSL and XPath specification were removed. There
   are now so many specifications and draft specifications relevant
   to XSL that it is more practical to simply point to W3C's XSL
   page.

3. A few typographical errors were corrected.

This information is posted to the XSL-List (and the XSL-List Digest)
at intervals under the subject line "XSL-List guidelines".

INTRODUCTION TO XSL-LIST

XSL-List hosts discussion of XSL itself, XSL applications and implementation,
and XSL user questions. XSL-List is open to everyone, users and developers,
experts and novices alike. There is no restriction to what may be posted on
the XSL-List provided it is related to XSL, which is considered to include
XSLT (versions 1 and 2), XPath (versions 1 and 2) and XSL Formatting Objects
(FO).

XSL-List is not a W3C mailing list, and has no affiliation with W3C (or any
official standing with any standards organization). However, XSL-List was
established with the encouragement of members of the W3C XSL Working Group,
and members of the Working Group are among the subscribers to the list.

Only subscribers can post to XSL-List, but since the goal is to increase the
level of XSL knowledge, XSL-List is being archived for everybody to view. The
topics being discussed on the XSL-List change as new ideas arise or existing
problems are dealt with, but the archive contains all of the ideas and
solutions that have been discussed on the list.

XSL-List is provided by Mulberry Technologies, Inc., as a service to the XSL
user community. Mulberry is an XML and SGML consultancy specializing in
applications that have a text design, processing, interchange, or display
component. For more information about Mulberry Technologies, Inc. see
http://www.mulberrytech.com


SUBSCRIBING TO THE XSL-LIST

To subscribe to the list, fill out the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html.


DAILY DIGEST

Daily digests -- copies of a whole days XSL-List messages sent as one email
message -- are available. Not only is it a single email message containing all
of that day's XSL-List messages, it is also half the size, on average, of the
individual messages since it doesn't include the overhead of the mail headers
from each message.

To unsubscribe from the list and subscribe to the digest, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html.


POSTING GUIDELINES

Only subscribers can post to XSL-List, and only from the exact address they
used when they subscribed.

There is no restriction on what may be posted to the XSL-List provided it is
related to XSL. Items concerning XML but without a direct connection to XSL
should be posted to a XML-related list instead of to the XSL-List. Items
related to DSSSL should be posted to the DSSSList.

Do not begin your subject line with "help" or "subscribe" since the list
software will bounce the message because it looks like is an administrative
request.

It is best to start a new message for a new thread. Do not start a new thread
by replying to an unrelated message and just changing the subject line, since
the header of your message will contain references to the previous message and
your new message will appear in the archive as one of the replies to the
original message.

Both subscribers to the full list (xsl-list@xxxxxxxxxxxxxxxxxxxxxx) and
subscribers to the digest (xsl-list-digest@xxxxxxxxxxxxxxxxxxxxxx) should post
their messages to xsl- list@xxxxxxxxxxxxxxxxxxxxxx; the messages will be
received by both subscribers to the list and subscribers to the digest.


BEFORE YOU POST ... DO YOUR HOMEWORK
- Check that your question isn't already answered in the XSL FAQ at
http://www.dpawson.co.uk/.
- Check that your question isn't already answered in the XSL-List archives at
http://www.biglist.com/lists/xsl-list/archives/.
- If you are asking for help with XSL code, determine which version of the
language you are using (plus extensions, if any), and confirm that your XSL
processor supports that version and/or extension. (If you are unsure of your
processor, this can be determined by using the stylesheet at
http://www.mulberrytech.com/xsl/xsl-list/processor-version.xsl on any input,
including the stylesheet itself: see
http://www.mulberrytech.com/xsl/xsl-list/processor-version.html for more
information.) An XSLT 1.0 engine will not process stylesheets written in XSLT
2.0!


IN YOUR POSTING ...

Name the XSL processor, processor version, and version of the language you are
using. This information is frequently necessary to diagnose a problem exactly,
and always helps respondents give good advice.

If you are replying to a post, trim the quoted message to just the parts to
which you are replying.

In addition to following simple rules of net etiquette and common sense, you
will improve the chances that you will receive prompt and helpful responses
by:
- Asking questions specific enough that answers are possible. Describe what
you are trying to do, how you approached it, what happened, and why you don't
like the result you got. Don't simply say "it gave me an error": paste in the
error message (someone else can probably make sense of it).
-  Illustrating your question with a demonstration of the problem.
Well-composed questions frequently include a small XML sample, an XSLT
stylesheet, the results received, and the result that was desired - all in
miniature, to make it comprehensible to readers new to your problem. (It is
also not uncommon to discover what a problem actually is in the process of
reducing it to an illustrative version.)


USE INFORMATIVE SUBJECT LINES

When posting to the XSL-List, do not use uninformative subject lines like
"Urgent", "Question", or "Newbie HELP!!!", which don't say anything about what
your problem is. Instead, use a meaningful subject line that will make sense
to the people whose help you are trying to get. It may even get a response
from people who normally shy away from "beginner" questions.

Informative subject lines make the XSL-List archive more useful since people
with the same problem will more easily find the relevant threads.


DO NOT CROSS-POST

Cross-posting to the XSL-List and to another list, even XML-Dev or the
DSSSList, is generally counter-productive. No list's archive will contain the
complete thread; cross-posts from non-subscribers continuing the thread will
bounce; and XSL-List subscribers who are not also on the other list will only
see half the thread, as will those on the other list who are not also reading
XSL- List. Subscribers to both lists may see two copies of the message,
annoying them as well.


REPLIES GO TO THE LIST

The reply address of XSL-List messages (and of digests) is
xsl-list@xxxxxxxxxxxxxxxxxxxxxx so REPLIES GO TO THE LIST BY DEFAULT. If you
want to reply to just the author of a post, you should change the "To:" field
in your reply.


USE SHORT QUOTES OF PREVIOUS MESSAGES IN REPLIES

Please do not quote entire messages just to add a few lines at the beginning
or end. Instead, quote the parts to which you are directly replying or quote
enough to establish the context.

Everybody on the list has already received the message that you are quoting,
and anyone searching the archive will find your message and the previous
message listed under the same thread.

Subscribers to the XSL-List will just ignore most of the quoted messages and
move to the next post, but subscribers to the XSL-List Digest will mostly have
to page past the quoted messages to reach the next material in which they are
interested in reading.


POSTINGS MUST BE IN PLAIN TEXT ONLY

Postings to XSL-List must be in plain text only. The XSL-List does not allow
HTML postings because many users cannot display them appropriately, and
because
they are unnecessarily large.


POSTINGS MAY NOT BE IN BASE 64

Postings to XSL-List may not be in Base 64 because it makes a mess of both the
digest and the archive.


ATTACHMENTS ARE BANNED

Since Mulberry's mailing lists have in the past been unwittingly used for
spreading viruses in e-mail attachments, all e-mail attachments are banned
from the XSL-List.

XSL stylesheets are XML files, and XML files are text files, so this does not
affect the majority of posts to the list since you can include the files' text
in the body of your message. If you need to refer to a binary file such as a
PDF file, you should put the file on a Web site or FTP site and include the
file's URL in your XSL-List post.

If you do include an attachment in your XSL-List post -- even a HTML
attachment -- your message will bounce.


YOUR POST WILL BE PERMANENTLY ARCHIVED

Because it is a public resource created by and for the entire XSL
community, we do not edit XSL-List. Therefore, it is responsibility of
list subscribers not to post anything to the list that they do not want
publicly available, possibly for a very long time.

Postings in the list archives will be complete, including: all contents,
examples, sample data, code or code fragments, and email header and footer
contents. An automated process will obscure the domain portion of email
addresses (the part after the @ sign).in the headers and footers of postings,
but no guarnantee is made that this process will be completely successfull.
Other than this, all postings will be archived in public as received.

Further, we at Mulberry could not, even if we wanted to, edit all of the
archives of XSL-List. Several third-parties have created unofficial archives
of
XSL-List, often without asking, or even informing, Mulberry. Postings to
XSL-List
will be included in an unknown and ever-changing variety of web publications.
If
you don't want your questions/comments/answers in public view don't post them
to
XSL-List.


THIRD-PARTY ARCHIVES OF XSL-LIST

Third parties are welcome to create searchable or reference archives of
XSL-List
provided they adhere to the following guidelines:
- the material is clearly labelled as being from XSL-List, with
 an acknowledgement of Mulberry's role as provider of XSL-List
- there is a navigable pointer to the official list page at
 http://www.mulberrytech.com/xsl/xsl-list/ either on every posting
 or associated with the user interface such that it is visible with
 the postings
- list postings are unedited
- either the entire archive of the list is provided or there is a
 clearly stated method for selecting the subset of the list that is provided

Mulberry does not provide these third parties with help to create these
archives, does not endorse particular third party archives, and has no control
over the ways in which they present the material in their systems.

People or organizations that publish the contents of XSL-List without
following
the guidelines above are being very antisocial. Please bookmark either
the official XSL-List archive or one provided by a service that plays nicely
in the community and shun those who do not give credit where credit it due.


UNSUBSCRIBING FROM THE XSL-LIST

To unsubscribe from XSL-List, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html. If you
have difficulties unsubscribing from the list:
 - make sure you are unsubscribing EXACTLY the email address that is
   subscribed
 - if you receive only one message a day from the list be sure to
   check the box marked "Select for the Digest version of the list"
   (if you subscribe to the digest and don't check this box the system
   will try to unsubscribe you from the regular list and fail; it will
   only unsubscribe you from the digest if you check this box.)

UNSUBSCRIBING FROM THE XSL-LIST DIGEST

To unsubscribe from the XSL-List digest, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html and
check the box marked "Select for the Digest version of the list".


IF YOU STOP GETTING XSL-LIST MESSAGES

If you stop receiving XSL-List message, you may have been removed because mail
to you was bouncing. You are not being picked on, and you can just rejoin the
list.


ARCHIVE

XSL-List messages are archived at
http://www.biglist.com/lists/xsl-list/archives/.


REPORTING BUGS IN SOFTWARE

Bugs in software should firstly be reported to its author rather than to the
XSL List. Questions regarding how to work around bugs are welcome, but the
list does not function as a bug-tracking system for any software.


XSL FAQ AND OTHER INFORMATION ON XSL

Dave Pawson's XSL FAQ is at http://www.dpawson.co.uk/xsl/index.html.

The W3C information on XSL is at http://www.w3.org/Style/XSL.

Mulberry's Quick References are at http://www.mulberrytech.com/quickref/ and
cover XSLT, XPath, and XQuery.


DSSSLIST -- THE DSSSL USERS' MAILING LIST

Mulberry Technologies, Inc., also provides the DSSSList -- the DSSSL Users'
Mailing List. For subscription information and the DSSSList archive, see
http://www.mulberrytech.com/dsssl/dssslist.


CONTACT

If you have any questions or problems, please contact
xsl-list-owner@xxxxxxxxxxxxxxxxxxxxxxx


ADMINISTRATIVE COMMUNICATIONS

The list administrator will reply to emailed questions relating to the
mechanics and administration of XSL-List and to help new users learn to use
the list. However, the administrator will not take the time to navigate mazes
of any sort in order to do so. If the list owner's messages are rejected by a
user's anti-spam system the list owner will not pursue the matter. Similarly,
if list-related notices to a subscriber are rejected as spam the subscriber
will be unsubscribed.



CHANGE History

==============
December 26, 2011 - btu.

11. Clarified instructions on unsubscribing from the digest version
    of the list.

==============
May 5, 2009 - btu.

10. Added paragraph clarifying that all content will be archived in
    public, including text, examples, code, and email headers and
    footers including names.

==============
February 1, 2008 - btu.

9. Policy on third-party archives added.

8. Policy banning attachments and postings in Base 64 clarified.

==============
September 1, 2007 - btu.

7. Administrative communication policy clarified.


==============
October 1, 2005 - btu.

6. Mulberry Technologies' relationship to XSL-List clarified. We
   do the work. We pay the bills. Organizations who post unauthorized
   copies of the archive without acknowledging Mulberry's contribution
   are not playing nicely in the community.

==============
March 2, 2005 - btu.

4. Users are asked to identify the version of XSLT and XPath
   they are using for questions that are specific to one version

5. Clarifying the policy on editing the list archive (we don't edit
   it).

==============
March 30, 2004 - btu.

1. All references to subscribing and unsubscribing have been
   updated to reflect changes in the list management system.

2. Pointers to the XSL and XPath specification were removed. There
   are now so many specifications and draft specifications relevant
   to XSL that it is more practical to simply point to W3C's XSL
   page.

3. A few typographical errors were corrected.

It's a very confused question. "tags" exist in lexical (angle-bracket) XML,
"nodes" exist in the tree representation of XML, and the two things are quite
distinct, so nodes can't appear within tags.

More particularly, element markup can't appear within CDATA tags. The whole
purpose of CDATA is to say "stuff in here that looks like markup is not markup
at all, it is ordinary characters".

So the answer is, generate characters that look like markup.

Using disable-output-escaping is completely wrong: d-o-e stops markup
characters being treated as plain text, whereas you want plain text to be
treated as markup characters.

Michael Kay
Saxonica


On 30 Apr 2013, at 14:16, Terry Ofner wrote:

> I need to generate the following format:
>
> <question>
> <![CDATA[The city council passed the new <strong>regulation</strong>.]]>
> </question>
>
> from this input:
>
> <question>The city council passed the new
<strong>regulation</strong>.></question>
>
> when I add cdata-section-elements="question" to my xsl:output statement, I
get this results:
>
> <question><![CDATA[6. The city council passed the new
]]><strong>regulation</strong><![CDATA[.]]></question>
>
>
> Is there a way to include the <strong> element in the CDATA?
>
> I have tried to convert the <strong> tag to text:
>
> <xsl:text
disable-output-escaping="yes">&amp;#x003C;strong&amp;#x003E;</xsl:text>
>        <xsl:apply-templates/>
> <xsl:text
disable-output-escaping="yes">&amp;#x003C;/strong&amp;#x003E;</xsl:text>
>
> but to no avail.
>
> I am using xslt 2.0
>
> Any help would be appreciated.
>
> Terry

It's a very confused question. "tags" exist in lexical (angle-bracket) XML,
"nodes" exist in the tree representation of XML, and the two things are quite
distinct, so nodes can't appear within tags.

More particularly, element markup can't appear within CDATA tags. The whole
purpose of CDATA is to say "stuff in here that looks like markup is not markup
at all, it is ordinary characters".

So the answer is, generate characters that look like markup.

Using disable-output-escaping is completely wrong: d-o-e stops markup
characters being treated as plain text, whereas you want plain text to be
treated as markup characters.

Michael Kay
Saxonica


On 30 Apr 2013, at 14:16, Terry Ofner wrote:

> I need to generate the following format:
>
> <question>
> <![CDATA[The city council passed the new <strong>regulation</strong>.]]>
> </question>
>
> from this input:
>
> <question>The city council passed the new
<strong>regulation</strong>.></question>
>
> when I add cdata-section-elements="question" to my xsl:output statement, I
get this results:
>
> <question><![CDATA[6. The city council passed the new
]]><strong>regulation</strong><![CDATA[.]]></question>
>
>
> Is there a way to include the <strong> element in the CDATA?
>
> I have tried to convert the <strong> tag to text:
>
> <xsl:text
disable-output-escaping="yes">&amp;#x003C;strong&amp;#x003E;</xsl:text>
>        <xsl:apply-templates/>
> <xsl:text
disable-output-escaping="yes">&amp;#x003C;/strong&amp;#x003E;</xsl:text>
>
> but to no avail.
>
> I am using xslt 2.0
>
> Any help would be appreciated.
>
> Terry

On 30 April 2013 14:16, Terry Ofner <tdofner@xxxxxxxxx> wrote:
> I need to generate the following format:
>
> <question>
> <![CDATA[The city council passed the new <strong>regulation</strong>.]]>
> </question>
>
> from this input:
>
> <question>The city council passed the new <strong>regulation</strong>.></question>
>
> when I add cdata-section-elements="question" to my xsl:output statement, I get this results:
>
> <question><![CDATA[6. The city council passed the new ]]><strong>regulation</strong><![CDATA[.]]></question>
>
>
> Is there a way to include the <strong> element in the CDATA?

You will need use the serialize() function in XSLT 3.0 on the
<question> contents, or the equivalent extension in 2.0.


-- 
Andrew Welch
http://andrewjwelch.com

I need to generate the following format:

<question>
<![CDATA[The city council passed the new <strong>regulation</strong>.]]>
</question>

from this input:

<question>The city council passed the new
<strong>regulation</strong>.></question>

when I add cdata-section-elements="question" to my xsl:output statement, I get
this results:

<question><![CDATA[6. The city council passed the new
]]><strong>regulation</strong><![CDATA[.]]></question>


Is there a way to include the <strong> element in the CDATA?

I have tried to convert the <strong> tag to text:

<xsl:text
disable-output-escaping="yes">&amp;#x003C;strong&amp;#x003E;</xsl:text>
        <xsl:apply-templates/>
<xsl:text
disable-output-escaping="yes">&amp;#x003C;/strong&amp;#x003E;</xsl:text>

but to no avail.

I am using xslt 2.0

Any help would be appreciated.

Terry

In XSLT 3.0 (XPath 3.0) one can use the parse-xml-fragment() function:

 <xsl:sequence select="parse-xml-fragment(question) /node()"/>
Cheers,
Dimitre

On Tue, Apr 30, 2013 at 6:16 AM, Terry Ofner <tdofner@xxxxxxxxx> wrote:
> I need to generate the following format:
>
> <question>
> <![CDATA[The city council passed the new <strong>regulation</strong>.]]>
> </question>
>
> from this input:
>
> <question>The city council passed the new <strong>regulation</strong>.></question>
>
> when I add cdata-section-elements="question" to my xsl:output statement, I get this results:
>
> <question><![CDATA[6. The city council passed the new ]]><strong>regulation</strong><![CDATA[.]]></question>
>
>
> Is there a way to include the <strong> element in the CDATA?
>
> I have tried to convert the <strong> tag to text:
>
> <xsl:text disable-output-escaping="yes">&amp;#x003C;strong&amp;#x003E;</xsl:text>
>         <xsl:apply-templates/>
> <xsl:text disable-output-escaping="yes">&amp;#x003C;/strong&amp;#x003E;</xsl:text>
>
> but to no avail.
>
> I am using xslt 2.0
>
> Any help would be appreciated.
>
> Terry
>



--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.

This information is posted to the XSL-List (and the XSL-List Digest)
at intervals under the subject line "XSL-List guidelines".

INTRODUCTION TO XSL-LIST

XSL-List hosts discussion of XSL itself, XSL applications and implementation,
and XSL user questions. XSL-List is open to everyone, users and developers,
experts and novices alike. There is no restriction to what may be posted on
the XSL-List provided it is related to XSL, which is considered to include
XSLT (versions 1 and 2), XPath (versions 1 and 2) and XSL Formatting Objects
(FO).

XSL-List is not a W3C mailing list, and has no affiliation with W3C (or any
official standing with any standards organization). However, XSL-List was
established with the encouragement of members of the W3C XSL Working Group,
and members of the Working Group are among the subscribers to the list.

Only subscribers can post to XSL-List, but since the goal is to increase the
level of XSL knowledge, XSL-List is being archived for everybody to view. The
topics being discussed on the XSL-List change as new ideas arise or existing
problems are dealt with, but the archive contains all of the ideas and
solutions that have been discussed on the list.

XSL-List is provided by Mulberry Technologies, Inc., as a service to the XSL
user community. Mulberry is an XML and SGML consultancy specializing in
applications that have a text design, processing, interchange, or display
component. For more information about Mulberry Technologies, Inc. see
http://www.mulberrytech.com


SUBSCRIBING TO THE XSL-LIST

To subscribe to the list, fill out the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html.


DAILY DIGEST

Daily digests -- copies of a whole days XSL-List messages sent as one email
message -- are available. Not only is it a single email message containing all
of that day's XSL-List messages, it is also half the size, on average, of the
individual messages since it doesn't include the overhead of the mail headers
from each message.

To unsubscribe from the list and subscribe to the digest, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html.


POSTING GUIDELINES

Only subscribers can post to XSL-List, and only from the exact address they
used when they subscribed.

There is no restriction on what may be posted to the XSL-List provided it is
related to XSL. Items concerning XML but without a direct connection to XSL
should be posted to a XML-related list instead of to the XSL-List. Items
related to DSSSL should be posted to the DSSSList.

Do not begin your subject line with "help" or "subscribe" since the list
software will bounce the message because it looks like is an administrative
request.

It is best to start a new message for a new thread. Do not start a new thread
by replying to an unrelated message and just changing the subject line, since
the header of your message will contain references to the previous message and
your new message will appear in the archive as one of the replies to the
original message.

Both subscribers to the full list (xsl-list@xxxxxxxxxxxxxxxxxxxxxx) and
subscribers to the digest (xsl-list-digest@xxxxxxxxxxxxxxxxxxxxxx) should post
their messages to xsl- list@xxxxxxxxxxxxxxxxxxxxxx; the messages will be
received by both subscribers to the list and subscribers to the digest.


BEFORE YOU POST ... DO YOUR HOMEWORK
- Check that your question isn't already answered in the XSL FAQ at
http://www.dpawson.co.uk/.
- Check that your question isn't already answered in the XSL-List archives at
http://www.biglist.com/lists/xsl-list/archives/.
- If you are asking for help with XSL code, determine which version of the
language you are using (plus extensions, if any), and confirm that your XSL
processor supports that version and/or extension. (If you are unsure of your
processor, this can be determined by using the stylesheet at
http://www.mulberrytech.com/xsl/xsl-list/processor-version.xsl on any input,
including the stylesheet itself: see
http://www.mulberrytech.com/xsl/xsl-list/processor-version.html for more
information.) An XSLT 1.0 engine will not process stylesheets written in XSLT
2.0!


IN YOUR POSTING ...

Name the XSL processor, processor version, and version of the language you are
using. This information is frequently necessary to diagnose a problem exactly,
and always helps respondents give good advice.

If you are replying to a post, trim the quoted message to just the parts to
which you are replying.

In addition to following simple rules of net etiquette and common sense, you
will improve the chances that you will receive prompt and helpful responses
by:
- Asking questions specific enough that answers are possible. Describe what
you are trying to do, how you approached it, what happened, and why you don't
like the result you got. Don't simply say "it gave me an error": paste in the
error message (someone else can probably make sense of it).
-  Illustrating your question with a demonstration of the problem.
Well-composed questions frequently include a small XML sample, an XSLT
stylesheet, the results received, and the result that was desired - all in
miniature, to make it comprehensible to readers new to your problem. (It is
also not uncommon to discover what a problem actually is in the process of
reducing it to an illustrative version.)


USE INFORMATIVE SUBJECT LINES

When posting to the XSL-List, do not use uninformative subject lines like
"Urgent", "Question", or "Newbie HELP!!!", which don't say anything about what
your problem is. Instead, use a meaningful subject line that will make sense
to the people whose help you are trying to get. It may even get a response
from people who normally shy away from "beginner" questions.

Informative subject lines make the XSL-List archive more useful since people
with the same problem will more easily find the relevant threads.


DO NOT CROSS-POST

Cross-posting to the XSL-List and to another list, even XML-Dev or the
DSSSList, is generally counter-productive. No list's archive will contain the
complete thread; cross-posts from non-subscribers continuing the thread will
bounce; and XSL-List subscribers who are not also on the other list will only
see half the thread, as will those on the other list who are not also reading
XSL- List. Subscribers to both lists may see two copies of the message,
annoying them as well.


REPLIES GO TO THE LIST

The reply address of XSL-List messages (and of digests) is
xsl-list@xxxxxxxxxxxxxxxxxxxxxx so REPLIES GO TO THE LIST BY DEFAULT. If you
want to reply to just the author of a post, you should change the "To:" field
in your reply.


USE SHORT QUOTES OF PREVIOUS MESSAGES IN REPLIES

Please do not quote entire messages just to add a few lines at the beginning
or end. Instead, quote the parts to which you are directly replying or quote
enough to establish the context.

Everybody on the list has already received the message that you are quoting,
and anyone searching the archive will find your message and the previous
message listed under the same thread.

Subscribers to the XSL-List will just ignore most of the quoted messages and
move to the next post, but subscribers to the XSL-List Digest will mostly have
to page past the quoted messages to reach the next material in which they are
interested in reading.


POSTINGS MUST BE IN PLAIN TEXT ONLY

Postings to XSL-List must be in plain text only. The XSL-List does not allow
HTML postings because many users cannot display them appropriately, and
because
they are unnecessarily large.


POSTINGS MAY NOT BE IN BASE 64

Postings to XSL-List may not be in Base 64 because it makes a mess of both the
digest and the archive.


ATTACHMENTS ARE BANNED

Since Mulberry's mailing lists have in the past been unwittingly used for
spreading viruses in e-mail attachments, all e-mail attachments are banned
from the XSL-List.

XSL stylesheets are XML files, and XML files are text files, so this does not
affect the majority of posts to the list since you can include the files' text
in the body of your message. If you need to refer to a binary file such as a
PDF file, you should put the file on a Web site or FTP site and include the
file's URL in your XSL-List post.

If you do include an attachment in your XSL-List post -- even a HTML
attachment -- your message will bounce.


YOUR POST WILL BE PERMANENTLY ARCHIVED

Because it is a public resource created by and for the entire XSL
community, we do not edit XSL-List. Therefore, it is responsibility of
list subscribers not to post anything to the list that they do not want
publicly available, possibly for a very long time.

Postings in the list archives will be complete, including: all contents,
examples, sample data, code or code fragments, and email header and footer
contents. An automated process will obscure the domain portion of email
addresses (the part after the @ sign).in the headers and footers of postings,
but no guarnantee is made that this process will be completely successfull.
Other than this, all postings will be archived in public as received.

Further, we at Mulberry could not, even if we wanted to, edit all of the
archives of XSL-List. Several third-parties have created unofficial archives
of
XSL-List, often without asking, or even informing, Mulberry. Postings to
XSL-List
will be included in an unknown and ever-changing variety of web publications.
If
you don't want your questions/comments/answers in public view don't post them
to
XSL-List.


THIRD-PARTY ARCHIVES OF XSL-LIST

Third parties are welcome to create searchable or reference archives of
XSL-List
provided they adhere to the following guidelines:
- the material is clearly labelled as being from XSL-List, with
 an acknowledgement of Mulberry's role as provider of XSL-List
- there is a navigable pointer to the official list page at
 http://www.mulberrytech.com/xsl/xsl-list/ either on every posting
 or associated with the user interface such that it is visible with
 the postings
- list postings are unedited
- either the entire archive of the list is provided or there is a
 clearly stated method for selecting the subset of the list that is provided

Mulberry does not provide these third parties with help to create these
archives, does not endorse particular third party archives, and has no control
over the ways in which they present the material in their systems.

People or organizations that publish the contents of XSL-List without
following
the guidelines above are being very antisocial. Please bookmark either
the official XSL-List archive or one provided by a service that plays nicely
in the community and shun those who do not give credit where credit it due.


UNSUBSCRIBING FROM THE XSL-LIST

To unsubscribe from XSL-List, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html. If you
have difficulties unsubscribing from the list:
 - make sure you are unsubscribing EXACTLY the email address that is
   subscribed
 - if you receive only one message a day from the list be sure to
   check the box marked "Select for the Digest version of the list"
   (if you subscribe to the digest and don't check this box the system
   will try to unsubscribe you from the regular list and fail; it will
   only unsubscribe you from the digest if you check this box.)

UNSUBSCRIBING FROM THE XSL-LIST DIGEST

To unsubscribe from the XSL-List digest, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html and
check the box marked "Select for the Digest version of the list".


IF YOU STOP GETTING XSL-LIST MESSAGES

If you stop receiving XSL-List message, you may have been removed because mail
to you was bouncing. You are not being picked on, and you can just rejoin the
list.


ARCHIVE

XSL-List messages are archived at
http://www.biglist.com/lists/xsl-list/archives/.


REPORTING BUGS IN SOFTWARE

Bugs in software should firstly be reported to its author rather than to the
XSL List. Questions regarding how to work around bugs are welcome, but the
list does not function as a bug-tracking system for any software.


XSL FAQ AND OTHER INFORMATION ON XSL

Dave Pawson's XSL FAQ is at http://www.dpawson.co.uk/xsl/index.html.

The W3C information on XSL is at http://www.w3.org/Style/XSL.

Mulberry's Quick References are at http://www.mulberrytech.com/quickref/ and
cover XSLT, XPath, and XQuery.


DSSSLIST -- THE DSSSL USERS' MAILING LIST

Mulberry Technologies, Inc., also provides the DSSSList -- the DSSSL Users'
Mailing List. For subscription information and the DSSSList archive, see
http://www.mulberrytech.com/dsssl/dssslist.


CONTACT

If you have any questions or problems, please contact
xsl-list-owner@xxxxxxxxxxxxxxxxxxxxxxx


ADMINISTRATIVE COMMUNICATIONS

The list administrator will reply to emailed questions relating to the
mechanics and administration of XSL-List and to help new users learn to use
the list. However, the administrator will not take the time to navigate mazes
of any sort in order to do so. If the list owner's messages are rejected by a
user's anti-spam system the list owner will not pursue the matter. Similarly,
if list-related notices to a subscriber are rejected as spam the subscriber
will be unsubscribed.



CHANGE History

==============
December 26, 2011 - btu.

11. Clarified instructions on unsubscribing from the digest version
    of the list.

==============
May 5, 2009 - btu.

10. Added paragraph clarifying that all content will be archived in
    public, including text, examples, code, and email headers and
    footers including names.

==============
February 1, 2008 - btu.

9. Policy on third-party archives added.

8. Policy banning attachments and postings in Base 64 clarified.

==============
September 1, 2007 - btu.

7. Administrative communication policy clarified.


==============
October 1, 2005 - btu.

6. Mulberry Technologies' relationship to XSL-List clarified. We
   do the work. We pay the bills. Organizations who post unauthorized
   copies of the archive without acknowledging Mulberry's contribution
   are not playing nicely in the community.

==============
March 2, 2005 - btu.

4. Users are asked to identify the version of XSLT and XPath
   they are using for questions that are specific to one version

5. Clarifying the policy on editing the list archive (we don't edit
   it).

==============
March 30, 2004 - btu.

1. All references to subscribing and unsubscribing have been
   updated to reflect changes in the list management system.

2. Pointers to the XSL and XPath specification were removed. There
   are now so many specifications and draft specifications relevant
   to XSL that it is more practical to simply point to W3C's XSL
   page.

3. A few typographical errors were corrected.

This information is posted to the XSL-List (and the XSL-List Digest)
at intervals under the subject line "XSL-List guidelines".

INTRODUCTION TO XSL-LIST

XSL-List hosts discussion of XSL itself, XSL applications and implementation,
and XSL user questions. XSL-List is open to everyone, users and developers,
experts and novices alike. There is no restriction to what may be posted on
the XSL-List provided it is related to XSL, which is considered to include
XSLT (versions 1 and 2), XPath (versions 1 and 2) and XSL Formatting Objects
(FO).

XSL-List is not a W3C mailing list, and has no affiliation with W3C (or any
official standing with any standards organization). However, XSL-List was
established with the encouragement of members of the W3C XSL Working Group,
and members of the Working Group are among the subscribers to the list.

Only subscribers can post to XSL-List, but since the goal is to increase the
level of XSL knowledge, XSL-List is being archived for everybody to view. The
topics being discussed on the XSL-List change as new ideas arise or existing
problems are dealt with, but the archive contains all of the ideas and
solutions that have been discussed on the list.

XSL-List is provided by Mulberry Technologies, Inc., as a service to the XSL
user community. Mulberry is an XML and SGML consultancy specializing in
applications that have a text design, processing, interchange, or display
component. For more information about Mulberry Technologies, Inc. see
http://www.mulberrytech.com


SUBSCRIBING TO THE XSL-LIST

To subscribe to the list, fill out the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html.


DAILY DIGEST

Daily digests -- copies of a whole days XSL-List messages sent as one email
message -- are available. Not only is it a single email message containing all
of that day's XSL-List messages, it is also half the size, on average, of the
individual messages since it doesn't include the overhead of the mail headers
from each message.

To unsubscribe from the list and subscribe to the digest, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html.


POSTING GUIDELINES

Only subscribers can post to XSL-List, and only from the exact address they
used when they subscribed.

There is no restriction on what may be posted to the XSL-List provided it is
related to XSL. Items concerning XML but without a direct connection to XSL
should be posted to a XML-related list instead of to the XSL-List. Items
related to DSSSL should be posted to the DSSSList.

Do not begin your subject line with "help" or "subscribe" since the list
software will bounce the message because it looks like is an administrative
request.

It is best to start a new message for a new thread. Do not start a new thread
by replying to an unrelated message and just changing the subject line, since
the header of your message will contain references to the previous message and
your new message will appear in the archive as one of the replies to the
original message.

Both subscribers to the full list (xsl-list@xxxxxxxxxxxxxxxxxxxxxx) and
subscribers to the digest (xsl-list-digest@xxxxxxxxxxxxxxxxxxxxxx) should post
their messages to xsl- list@xxxxxxxxxxxxxxxxxxxxxx; the messages will be
received by both subscribers to the list and subscribers to the digest.


BEFORE YOU POST ... DO YOUR HOMEWORK
- Check that your question isn't already answered in the XSL FAQ at
http://www.dpawson.co.uk/.
- Check that your question isn't already answered in the XSL-List archives at
http://www.biglist.com/lists/xsl-list/archives/.
- If you are asking for help with XSL code, determine which version of the
language you are using (plus extensions, if any), and confirm that your XSL
processor supports that version and/or extension. (If you are unsure of your
processor, this can be determined by using the stylesheet at
http://www.mulberrytech.com/xsl/xsl-list/processor-version.xsl on any input,
including the stylesheet itself: see
http://www.mulberrytech.com/xsl/xsl-list/processor-version.html for more
information.) An XSLT 1.0 engine will not process stylesheets written in XSLT
2.0!


IN YOUR POSTING ...

Name the XSL processor, processor version, and version of the language you are
using. This information is frequently necessary to diagnose a problem exactly,
and always helps respondents give good advice.

If you are replying to a post, trim the quoted message to just the parts to
which you are replying.

In addition to following simple rules of net etiquette and common sense, you
will improve the chances that you will receive prompt and helpful responses
by:
- Asking questions specific enough that answers are possible. Describe what
you are trying to do, how you approached it, what happened, and why you don't
like the result you got. Don't simply say "it gave me an error": paste in the
error message (someone else can probably make sense of it).
-  Illustrating your question with a demonstration of the problem.
Well-composed questions frequently include a small XML sample, an XSLT
stylesheet, the results received, and the result that was desired - all in
miniature, to make it comprehensible to readers new to your problem. (It is
also not uncommon to discover what a problem actually is in the process of
reducing it to an illustrative version.)


USE INFORMATIVE SUBJECT LINES

When posting to the XSL-List, do not use uninformative subject lines like
"Urgent", "Question", or "Newbie HELP!!!", which don't say anything about what
your problem is. Instead, use a meaningful subject line that will make sense
to the people whose help you are trying to get. It may even get a response
from people who normally shy away from "beginner" questions.

Informative subject lines make the XSL-List archive more useful since people
with the same problem will more easily find the relevant threads.


DO NOT CROSS-POST

Cross-posting to the XSL-List and to another list, even XML-Dev or the
DSSSList, is generally counter-productive. No list's archive will contain the
complete thread; cross-posts from non-subscribers continuing the thread will
bounce; and XSL-List subscribers who are not also on the other list will only
see half the thread, as will those on the other list who are not also reading
XSL- List. Subscribers to both lists may see two copies of the message,
annoying them as well.


REPLIES GO TO THE LIST

The reply address of XSL-List messages (and of digests) is
xsl-list@xxxxxxxxxxxxxxxxxxxxxx so REPLIES GO TO THE LIST BY DEFAULT. If you
want to reply to just the author of a post, you should change the "To:" field
in your reply.


USE SHORT QUOTES OF PREVIOUS MESSAGES IN REPLIES

Please do not quote entire messages just to add a few lines at the beginning
or end. Instead, quote the parts to which you are directly replying or quote
enough to establish the context.

Everybody on the list has already received the message that you are quoting,
and anyone searching the archive will find your message and the previous
message listed under the same thread.

Subscribers to the XSL-List will just ignore most of the quoted messages and
move to the next post, but subscribers to the XSL-List Digest will mostly have
to page past the quoted messages to reach the next material in which they are
interested in reading.


POSTINGS MUST BE IN PLAIN TEXT ONLY

Postings to XSL-List must be in plain text only. The XSL-List does not allow
HTML postings because many users cannot display them appropriately, and
because
they are unnecessarily large.


POSTINGS MAY NOT BE IN BASE 64

Postings to XSL-List may not be in Base 64 because it makes a mess of both the
digest and the archive.


ATTACHMENTS ARE BANNED

Since Mulberry's mailing lists have in the past been unwittingly used for
spreading viruses in e-mail attachments, all e-mail attachments are banned
from the XSL-List.

XSL stylesheets are XML files, and XML files are text files, so this does not
affect the majority of posts to the list since you can include the files' text
in the body of your message. If you need to refer to a binary file such as a
PDF file, you should put the file on a Web site or FTP site and include the
file's URL in your XSL-List post.

If you do include an attachment in your XSL-List post -- even a HTML
attachment -- your message will bounce.


YOUR POST WILL BE PERMANENTLY ARCHIVED

Because it is a public resource created by and for the entire XSL
community, we do not edit XSL-List. Therefore, it is responsibility of
list subscribers not to post anything to the list that they do not want
publicly available, possibly for a very long time.

Postings in the list archives will be complete, including: all contents,
examples, sample data, code or code fragments, and email header and footer
contents. An automated process will obscure the domain portion of email
addresses (the part after the @ sign).in the headers and footers of postings,
but no guarnantee is made that this process will be completely successfull.
Other than this, all postings will be archived in public as received.

Further, we at Mulberry could not, even if we wanted to, edit all of the
archives of XSL-List. Several third-parties have created unofficial archives
of
XSL-List, often without asking, or even informing, Mulberry. Postings to
XSL-List
will be included in an unknown and ever-changing variety of web publications.
If
you don't want your questions/comments/answers in public view don't post them
to
XSL-List.


THIRD-PARTY ARCHIVES OF XSL-LIST

Third parties are welcome to create searchable or reference archives of
XSL-List
provided they adhere to the following guidelines:
- the material is clearly labelled as being from XSL-List, with
 an acknowledgement of Mulberry's role as provider of XSL-List
- there is a navigable pointer to the official list page at
 http://www.mulberrytech.com/xsl/xsl-list/ either on every posting
 or associated with the user interface such that it is visible with
 the postings
- list postings are unedited
- either the entire archive of the list is provided or there is a
 clearly stated method for selecting the subset of the list that is provided

Mulberry does not provide these third parties with help to create these
archives, does not endorse particular third party archives, and has no control
over the ways in which they present the material in their systems.

People or organizations that publish the contents of XSL-List without
following
the guidelines above are being very antisocial. Please bookmark either
the official XSL-List archive or one provided by a service that plays nicely
in the community and shun those who do not give credit where credit it due.


UNSUBSCRIBING FROM THE XSL-LIST

To unsubscribe from XSL-List, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html. If you
have difficulties unsubscribing from the list:
 - make sure you are unsubscribing EXACTLY the email address that is
   subscribed
 - if you receive only one message a day from the list be sure to
   check the box marked "Select for the Digest version of the list"
   (if you subscribe to the digest and don't check this box the system
   will try to unsubscribe you from the regular list and fail; it will
   only unsubscribe you from the digest if you check this box.)

UNSUBSCRIBING FROM THE XSL-LIST DIGEST

To unsubscribe from the XSL-List digest, use the form at
http://www.mulberrytech.com/xsl/xsl-list/subscribe-unsubscribe.html and
check the box marked "Select for the Digest version of the list".


IF YOU STOP GETTING XSL-LIST MESSAGES

If you stop receiving XSL-List message, you may have been removed because mail
to you was bouncing. You are not being picked on, and you can just rejoin the
list.


ARCHIVE

XSL-List messages are archived at
http://www.biglist.com/lists/xsl-list/archives/.


REPORTING BUGS IN SOFTWARE

Bugs in software should firstly be reported to its author rather than to the
XSL List. Questions regarding how to work around bugs are welcome, but the
list does not function as a bug-tracking system for any software.


XSL FAQ AND OTHER INFORMATION ON XSL

Dave Pawson's XSL FAQ is at http://www.dpawson.co.uk/xsl/index.html.

The W3C information on XSL is at http://www.w3.org/Style/XSL.

Mulberry's Quick References are at http://www.mulberrytech.com/quickref/ and
cover XSLT, XPath, and XQuery.


DSSSLIST -- THE DSSSL USERS' MAILING LIST

Mulberry Technologies, Inc., also provides the DSSSList -- the DSSSL Users'
Mailing List. For subscription information and the DSSSList archive, see
http://www.mulberrytech.com/dsssl/dssslist.


CONTACT

If you have any questions or problems, please contact
xsl-list-owner@xxxxxxxxxxxxxxxxxxxxxxx


ADMINISTRATIVE COMMUNICATIONS

The list administrator will reply to emailed questions relating to the
mechanics and administration of XSL-List and to help new users learn to use
the list. However, the administrator will not take the time to navigate mazes
of any sort in order to do so. If the list owner's messages are rejected by a
user's anti-spam system the list owner will not pursue the matter. Similarly,
if list-related notices to a subscriber are rejected as spam the subscriber
will be unsubscribed.



CHANGE History

==============
December 26, 2011 - btu.

11. Clarified instructions on unsubscribing from the digest version
    of the list.

==============
May 5, 2009 - btu.

10. Added paragraph clarifying that all content will be archived in
    public, including text, examples, code, and email headers and
    footers including names.

==============
February 1, 2008 - btu.

9. Policy on third-party archives added.

8. Policy banning attachments and postings in Base 64 clarified.

==============
September 1, 2007 - btu.

7. Administrative communication policy clarified.


==============
October 1, 2005 - btu.

6. Mulberry Technologies' relationship to XSL-List clarified. We
   do the work. We pay the bills. Organizations who post unauthorized
   copies of the archive without acknowledging Mulberry's contribution
   are not playing nicely in the community.

==============
March 2, 2005 - btu.

4. Users are asked to identify the version of XSLT and XPath
   they are using for questions that are specific to one version

5. Clarifying the policy on editing the list archive (we don't edit
   it).

==============
March 30, 2004 - btu.

1. All references to subscribing and unsubscribing have been
   updated to reflect changes in the list management system.

2. Pointers to the XSL and XPath specification were removed. There
   are now so many specifications and draft specifications relevant
   to XSL that it is more practical to simply point to W3C's XSL
   page.

3. A few typographical errors were corrected.

------------------------------

At 2013-04-25 01:29 +0900, Toshihiko Makita wrote:

I'm making a stylesheet that converts DITA documents to XSL-FO.

Actually, the answer is a *lot* simpler than I thought because I
misread your request to convert DITA to DITA and because you made
reference to a morerows attribute.  The principle is the same, but in
XSL-FO one can take advantage of the cell-based row-grouping
approach.  I even have an example of this as an exercise in my
training class in the module on sorting and grouping.  Most of my
students have never heard of filling an XSL-FO table with only cell
elements and not row elements, so the exercise is meant to help
remember the technique.

Usually a table is authored with entry/@morerows attribute. But
some table has no @morerows attribute.

In XSL-FO it is acceptable to say number-rows-spanned="1" when there
is no spanning.  I don't know if it is allowed to say morerows="0" in DITA.

It would help us help you to have the XML input data of your table
example.  You can post it as clear text in your message and we can
cut it out and create a file from it.

I mocked up a test file that mimics your data and produces an
acceptable XSL-FO result using a simplified stylesheet.  Note the use
of the ends-row="true/false" attribute and that there are no
<table-row> elements.  The output test.fo can be formatted with an
XSL-FO engine to produce a result with the rows you need.

t:\ftemp>type test.xml
<?xml version="1.0" encoding="UTF-8"?>
<table>
    <tgroup>
      <tbody>
        <row><entry>A</entry><entry>B</entry><entry>C</entry><entry>D</entry><entry>E</entry><entry>F</entry></row>
        <row><entry>A</entry><entry>G</entry><entry>H</entry><entry>I</entry><entry>J</entry><entry>K</entry></row>
        <row><entry>A</entry><entry>G</entry><entry>H</entry><entry>L</entry><entry>M</entry><entry>N</entry></row>
        <row><entry>A</entry><entry>G</entry><entry>O</entry><entry>P</entry><entry>M</entry><entry>Q</entry></row>
        <row><entry>A</entry><entry>G</entry><entry>R</entry><entry>S</entry><entry>T</entry><entry>Q</entry></row>
        <row><entry>A</entry><entry>G</entry><entry>V</entry><entry>S</entry><entry>W</entry><entry>X</entry></row>
        <row><entry>A</entry><entry>Y</entry><entry>Z</entry><entry>1</entry><entry>2</entry><entry>3</entry></row>
        <row><entry>A</entry><entry>Y</entry><entry>4</entry><entry>1</entry><entry>5</entry><entry>6</entry></row>
        <row><entry>A</entry><entry>Y</entry><entry>7</entry><entry>1</entry><entry>5</entry><entry>8</entry></row>
      </tbody>
    </tgroup>
</table>

t:\ftemp>call xslt2 test.xml testfo.xsl test.fo

t:\ftemp>type testfo.xsl
<?xml version="1.0" encoding="UTF-8"?>
<root xmlns="http://www.w3.org/1999/XSL/Format"
        font-family="Times" font-size="20pt"
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
        xsl:version="2.0">

    <layout-master-set>
      <simple-page-master master-name="frame"
                          page-height="11in" page-width="8.5in"
                          margin-top=".5in" margin-bottom=".5in"
                          margin-left=".5in" margin-right=".5in">
        <region-body region-name="frame-body"/>
      </simple-page-master>
    </layout-master-set>

    <page-sequence master-reference="frame">
      <flow flow-name="frame-body">
        <block>This is a test of spanning rows in XSL-FO</block>

<table text-align="center">
    <table-body>
      <xsl:for-each select="table/tgroup/tbody">
      <!--create a stream of table cells, marking the end of each row-->
        <!--only the first three columns of the table are grouped-->
        <xsl:for-each-group select="row" group-by="entry[1]">
          <table-cell number-rows-spanned="{count(current-group())[.>1]}">
            <block>
              <xsl:apply-templates select="entry[1]/node()"/>
            </block>
          </table-cell>
          <xsl:for-each-group select="current-group()" group-by="entry[2]">
            <table-cell number-rows-spanned="{count(current-group())[.>1]}">
              <block>
                <xsl:apply-templates select="entry[2]/node()"/>
              </block>
            </table-cell>
            <xsl:for-each-group select="current-group()" group-by="entry[3]">
              <table-cell number-rows-spanned="{count(current-group())[.>1]}">
                <block>
                  <xsl:apply-templates select="entry[3]/node()"/>
                </block>
              </table-cell>
              <!--the rest of the columns are not grouped-->
              <xsl:for-each select="current-group()">
                <xsl:for-each select="entry[position()>3]">
                  <!--mark the last cell of each row as true, others as false-->
                  <table-cell ends-row="{position()=last()}">
                   <block>
                     <xsl:apply-templates/>
                   </block>
                  </table-cell>
                </xsl:for-each>
              </xsl:for-each>
            </xsl:for-each-group>
          </xsl:for-each-group>
        </xsl:for-each-group>
      </xsl:for-each>
    </table-body>
</table>

      </flow>
    </page-sequence>
</root>

t:\ftemp>rem Done!

Since I had already written a DITA -> DITA stylesheet adding
morerows= before discovering I misread your question, I've added
below a stylesheet that does that with the same input data:

t:\ftemp>type test.xml
<?xml version="1.0" encoding="UTF-8"?>
<table>
    <tgroup>
      <tbody>
        <row><entry>A</entry><entry>B</entry><entry>C</entry><entry>D</entry><entry>E</entry><entry>F</entry></row>
        <row><entry>A</entry><entry>G</entry><entry>H</entry><entry>I</entry><entry>J</entry><entry>K</entry></row>
        <row><entry>A</entry><entry>G</entry><entry>H</entry><entry>L</entry><entry>M</entry><entry>N</entry></row>
        <row><entry>A</entry><entry>G</entry><entry>O</entry><entry>P</entry><entry>M</entry><entry>Q</entry></row>
        <row><entry>A</entry><entry>G</entry><entry>R</entry><entry>S</entry><entry>T</entry><entry>Q</entry></row>
        <row><entry>A</entry><entry>G</entry><entry>V</entry><entry>S</entry><entry>W</entry><entry>X</entry></row>
        <row><entry>A</entry><entry>Y</entry><entry>Z</entry><entry>1</entry><entry>2</entry><entry>3</entry></row>
        <row><entry>A</entry><entry>Y</entry><entry>4</entry><entry>1</entry><entry>5</entry><entry>6</entry></row>
        <row><entry>A</entry><entry>Y</entry><entry>7</entry><entry>1</entry><entry>5</entry><entry>8</entry></row>
      </tbody>
    </tgroup>
</table>

t:\ftemp>call xslt2 test.xml testdita.xsl test.out.xml

t:\ftemp>type test.out.xml
<?xml version="1.0" encoding="UTF-8"?><table>
    <tgroup>
      <tbody>
<row><entry
morerows="8">A</entry><entry>B</entry><entry>C</entry><entry>D</entry><entry>E</entry><entry>F</entry></row>
<row><entry morerows="4">G</entry><entry
morerows="1">H</entry><entry>I</entry><entry>J</entry><entry>K</entry></row>
<row><entry>L</entry><entry>M</entry><entry>N</entry></row>
<row><entry>O</entry><entry>P</entry><entry>M</entry><entry>Q</entry></row>
<row><entry>R</entry><entry>S</entry><entry>T</entry><entry>Q</entry></row>
<row><entry>V</entry><entry>S</entry><entry>W</entry><entry>X</entry></row>
<row><entry
morerows="2">Y</entry><entry>Z</entry><entry>1</entry><entry>2</entry><entry>3</entry></row>
<row><entry>4</entry><entry>1</entry><entry>5</entry><entry>6</entry></row>
<row><entry>7</entry><entry>1</entry><entry>5</entry><entry>8</entry></row></tbody>
    </tgroup>
</table>
t:\ftemp>type testdita.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
    version="2.0">

<xsl:template match="tbody">
    <xsl:copy>
      <xsl:apply-templates select="@*"/>
      <!--create a stream of entries, marking the end of each row-->
      <xsl:variable name="stream-entries" as="element()*">
        <!--only the first three columns of the table are grouped-->
        <xsl:for-each-group select="row" group-by="entry[1]">
          <entry>
            <xsl:copy-of select="entry[1]/@*"/>
            <xsl:for-each select="count(current-group())[.>1]">
              <xsl:attribute name="morerows" select=".-1"/>
            </xsl:for-each>
            <xsl:copy-of select="entry[1]/node()"/>
          </entry>
          <xsl:for-each-group select="current-group()" group-by="entry[2]">
            <entry>
              <xsl:copy-of select="entry[2]/@*"/>
              <xsl:for-each select="count(current-group())[.>1]">
                <xsl:attribute name="morerows" select=".-1"/>
              </xsl:for-each>
              <xsl:copy-of select="entry[2]/node()"/>
            </entry>
            <xsl:for-each-group select="current-group()" group-by="entry[3]">
              <entry>
                <xsl:copy-of select="entry[3]/@*"/>
                <xsl:for-each select="count(current-group())[.>1]">
                  <xsl:attribute name="morerows" select=".-1"/>
                </xsl:for-each>
                <xsl:copy-of select="entry[3]/node()"/>
              </entry>
              <!--the rest of the columns are not grouped-->
              <xsl:for-each select="current-group()">
                <xsl:copy-of select="entry[position()>3]"/>
                <!--mark the end of each row for compartmentalization-->
                <row-ends-here/>
              </xsl:for-each>
            </xsl:for-each-group>
          </xsl:for-each-group>
        </xsl:for-each-group>
      </xsl:variable>
      <!--reconstitute rows from the stream of entries by finding each
row end-->
      <xsl:for-each-group select="$stream-entries"
                          group-ending-with="row-ends-here">
        <xsl:text>&#xa;</xsl:text>
        <row>
          <xsl:copy-of select="current-group()[position()&lt;last()]"/>
        </row>
      </xsl:for-each-group>
    </xsl:copy>
</xsl:template>

<xsl:template match="@*|node()"><!--identity for all other nodes-->
    <xsl:copy>
      <xsl:apply-templates select="@*|node()"/>
    </xsl:copy>
</xsl:template>

</xsl:stylesheet>
t:\ftemp>rem Done!

I hope these examples help.

. . . . . . . . . Ken

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

------------------------------

On Thu, April 25, 2013 9:04 pm, Eric J. Bowman wrote:
> Dimitre Novatchev wrote:
>>
>> Alas, I am not one of the browser vendors... but these people probably
>> can make logical conclusions?
>
> Yes, they've logically concluded that they can dictate which
> technologies are "inappropriate" for use in browsers.  Can't imagine
> this has anything to do with _improving_ XSLT performance, or updating
> to 2.0 / Saxon CE, so much as their obvious agenda to kill XML on the
> Web.

"Logic is a systematic method of coming to the wrong conclusion with
confidence" [1]

However, even yesterday, the thread at
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/KZ0eaL-3vQY
was about measuring usage, not arbitrarily dropping XSLT, and that was
reiterated there after several posts in support of XSLT.

Several of the posts on that thread have pointed out what we could
consider to be obvious: poor support for XSLT in browsers has led to poor
usage of XSLT in browsers.  But because of that poor support, even a
well-intentioned usage statistics gathering will, I fear, be like a train
company considering going from an hourly service to a half-hourly that
then drops the idea after its survey shows people only gather at the train
station at hourly intervals.

Collectively, here, we mostly think it's a no-brainer to use XSLT in the
browser, and even XSLT 2.0 in the browser with Saxon-CE, though many would
not have heard of blink until yesterday, but collectively, on the blink
list, they'd mostly think you'd have no brains if you use XSLT in the
browser, and many would not have heard of Saxon-CE until yesterday. 
There's obviously more than a little distance between those two positions,
but how would you positively influence them towards our position?

Regards,


Tony Graham                                   tgraham@xxxxxxxxxx
Consultant                                 http://www.mentea.net
Mentea       13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
 --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
    XML, XSL-FO and XSLT consulting, training and programming


[1] http://www.netlingo.com/word/murphys-laws-on-technology.php
    and various other places.  I originally saw it on a poster
    of the same name, but most sites that quote all the maxims
    from the poster neglect to mention the original.

"Tony Graham" wrote:
>
> There's obviously more than a little distance between those two
> positions, but how would you positively influence them towards our
> position?
> 

After years of watching every issue I care about get decided the other
way by the browser vendors, I'd have to say I doubt positive influence
is possible on XSLT.  If XSLT survives as a Web technology, it'll be as
a plugin, a la Flash.

http://lists.w3.org/Archives/Public/www-tag/2013Feb/0060.html
http://lists.w3.org/Archives/Public/www-tag/2013Feb/0075.html
http://lists.w3.org/Archives/Public/www-tag/2013Feb/0077.html
http://lists.w3.org/Archives/Public/www-tag/2013Feb/0089.html
http://lists.w3.org/Archives/Public/www-tag/2013Feb/0104.html

That's called "tilting at windmills," but props to anyone else who
wants to try.

-Eric

On 25 Apr 2013, at 07:36, davep wrote:

> On 24/04/13 18:29, Michael Kay wrote:
>> I thought that some of you who like to stay close to the bleeding edge
might like to try out some of the new XSLT 3.0 features implemented in Saxon
9.5.
>>
>
> Is 9.5 fully compliant to the spec now Mike? As it currently stands?

XPath 3.0 is now very stable, there's a very complete test suite, and Saxon is
100% conformant (well, it was last Thursday; there's always a trickle of spec
bugs and Saxon bugs that makes that figure oscillate between 99.99% and
100%).

XSLT 3.0 has not yet reached that level of stability. There are some parts
Saxon doesn't implement at all yet (notably the "packaging" features), there
are some parts where Saxon hasn't caught up with the latest changes, and there
some parts where Saxon implements features or changes to features that the WG
hasn't published yet. It's a work in progress.

Michael Kay
Saxonica

Dimitre Novatchev wrote:
> 
> Alas, I am not one of the browser vendors... but these people probably
> can make logical conclusions?
> 

Yes, they've logically concluded that they can dictate which
technologies are "inappropriate" for use in browsers.  Can't imagine
this has anything to do with _improving_ XSLT performance, or updating
to 2.0 / Saxon CE, so much as their obvious agenda to kill XML on the
Web.

-Eric

Yes Mike, awaiting to implement it here!

Regards,

Arulselvan R Pallavarayar
Senior Software Engineer | MPS Limited
RR Tower -4 | Super-A, 16 &17 4th floor| TVK industrial Estate | Guindy |
Chennai | 600032 | INDIA

Direct: +91 (0)44 4916 2259 | Ext 259
Mobile: +91 (0)9710416093
Email: arul.selvan@xxxxxxxxxxx
www.adi-mps.com
-----Original Message-----
From: davep [mailto:davep@xxxxxxxxxxxxx]
Sent: Thursday, April 25, 2013 12:07 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re:  XSLT 3.0 features in Saxon 9.5

On 24/04/13 18:29, Michael Kay wrote:
> I thought that some of you who like to stay close to the bleeding edge
might like to try out some of the new XSLT 3.0 features implemented in Saxon
9.5.
>

Is 9.5 fully compliant to the spec now Mike? As it currently stands?
I know you do a lot of testing.




regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

This e-mail and/or attachments are confidential and may also be legally
privileged. If you are not the intended recipient, any disclosure, copying,
distribution or action taken relying on the contents is strictly prohibited
and may be unlawful. If you have received this communication in error, please
notify the sender immediately by responding to this e-mail and deleting the
contents of the e-mail & related attachments from your system. Though MPS
Limited has taken reasonable steps to ensure no viruses are present in this
e-mail, it cannot accept responsibility for any loss or damage arising from
the use of this e-mail or attachments. No contracts may be concluded with MPS
through e-mail communication. Please consider the environment before printing
this e-mail.

On Thu, 2013-04-25 at 07:36 +0100, davep wrote:
> On 24/04/13 18:29, Michael Kay wrote:
> > I thought that some of you who like to stay close to the bleeding edge might like to try out some of the new XSLT 3.0 features implemented in Saxon 9.5.
> >
> 
> Is 9.5 fully compliant to the spec now Mike? As it currently stands?
> I know you do a lot of testing.

I know you were asking Mike, but I'll point out that XSLT 3 is a working
draft and very much subject to change. I think this is the meaning of
the "bleeding-edge" part of the announcement...

Nor is it really sane to ask whether it's bug-free :)

Saxon does have one of the most complete and careful implementations of
XQuery 1 and XSLT 2 on the planet as far as I can tell.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

I thought that some of you who like to stay close to the bleeding edge might like to try out some of the new XSLT 3.0 features implemented in Saxon 9.5.

Is 9.5 fully compliant to the spec now Mike? As it currently stands?
I know you do a lot of testing.

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

I thought that some of you who like to stay close to the bleeding edge might
like to try out some of the new XSLT 3.0 features implemented in Saxon 9.5.

These include:

* composite grouping keys

for example <xsl:for-each-group group-by="first, last" composite="yes">

* accumulators (a big subject that deserves a tutorial)

* xsl:number start-at="5" to start numbering from something other than 1.

* xsl:assert

* xsl:map and xsl:map-entry so you can now construct maps at the XSLT level,
not only at the XPath level

* content value templates, for example

<title>Chapter {$number}</title>

- needs to be enabled with expand-text="yes" for compatibility reasons

- unlike XQuery, the expansion always yields a string, not elements or
attributes.



Accumulators, like xsl:iterate and some other XSLT 3.0 features, were
introduced primarily for streaming use cases, but I think they might well
prove handy even where streaming isn't a requirement. They basically give you
the ability to compute a value during a tree-walk of a document, passing the
accumulated value both up and down the tree; in FP terms, a sort of tree-fold
operation. If we didn't already have xsl:key, for example, you could use an
accumulator to construct an index for a document in the form of a map. I'm
sure there are people on this list who will come up with creative applications
for them...

Saxon releases don't coincide exactly with W3C working drafts so some of the
features implemented in 9.5 won't actually be published until the next WD, and
in some cases there may have been spec changes between the last public WD and
the Saxon implementation. I did say it was bleeding edge.

Michael Kay
Saxonica

At 2013-04-25 01:29 +0900, Toshihiko Makita wrote:

I'm making a stylesheet that converts DITA documents to XSL-FO.

Usually a table is authored with entry/@morerows attribute. But some table has no @morerows attribute.

It would help us help you to have the XML input data of your table example. You can post it as clear text in your message and we can cut it out and create a file from it.

t:\ftemp>type test.xml
<?xml version="1.0" encoding="UTF-8"?>
<table>
  <tgroup>
    <tbody>
      <row><entry>A</entry><entry>B</entry><entry>C</entry><entry>D</entry><entry>E</entry><entry>F</entry></row>
      <row><entry>A</entry><entry>G</entry><entry>H</entry><entry>I</entry><entry>J</entry><entry>K</entry></row>
      <row><entry>A</entry><entry>G</entry><entry>H</entry><entry>L</entry><entry>M</entry><entry>N</entry></row>
      <row><entry>A</entry><entry>G</entry><entry>O</entry><entry>P</entry><entry>M</entry><entry>Q</entry></row>
      <row><entry>A</entry><entry>G</entry><entry>R</entry><entry>S</entry><entry>T</entry><entry>Q</entry></row>
      <row><entry>A</entry><entry>G</entry><entry>V</entry><entry>S</entry><entry>W</entry><entry>X</entry></row>
      <row><entry>A</entry><entry>Y</entry><entry>Z</entry><entry>1</entry><entry>2</entry><entry>3</entry></row>
      <row><entry>A</entry><entry>Y</entry><entry>4</entry><entry>1</entry><entry>5</entry><entry>6</entry></row>
      <row><entry>A</entry><entry>Y</entry><entry>7</entry><entry>1</entry><entry>5</entry><entry>8</entry></row>
    </tbody>
  </tgroup>
</table>

t:\ftemp>type testfo.xsl
<?xml version="1.0" encoding="UTF-8"?>
<root xmlns="http://www.w3.org/1999/XSL/Format"
      font-family="Times" font-size="20pt"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xsl:version="2.0">

  <layout-master-set>
    <simple-page-master master-name="frame"
                        page-height="11in" page-width="8.5in"
                        margin-top=".5in" margin-bottom=".5in"
                        margin-left=".5in" margin-right=".5in">
      <region-body region-name="frame-body"/>
    </simple-page-master>
  </layout-master-set>

  <page-sequence master-reference="frame">
    <flow flow-name="frame-body">
      <block>This is a test of spanning rows in XSL-FO</block>

<table text-align="center">
  <table-body>
    <xsl:for-each select="table/tgroup/tbody">
    <!--create a stream of table cells, marking the end of each row-->
      <!--only the first three columns of the table are grouped-->
      <xsl:for-each-group select="row" group-by="entry[1]">
        <table-cell number-rows-spanned="{count(current-group())[.>1]}">
          <block>
            <xsl:apply-templates select="entry[1]/node()"/>
          </block>
        </table-cell>
        <xsl:for-each-group select="current-group()" group-by="entry[2]">
          <table-cell number-rows-spanned="{count(current-group())[.>1]}">
            <block>
              <xsl:apply-templates select="entry[2]/node()"/>
            </block>
          </table-cell>
          <xsl:for-each-group select="current-group()" group-by="entry[3]">
            <table-cell number-rows-spanned="{count(current-group())[.>1]}">
              <block>
                <xsl:apply-templates select="entry[3]/node()"/>
              </block>
            </table-cell>
            <!--the rest of the columns are not grouped-->
            <xsl:for-each select="current-group()">
              <xsl:for-each select="entry[position()>3]">
                <!--mark the last cell of each row as true, others as false-->
                <table-cell ends-row="{position()=last()}">
                 <block>
                   <xsl:apply-templates/>
                 </block>
                </table-cell>
              </xsl:for-each>
            </xsl:for-each>
          </xsl:for-each-group>
        </xsl:for-each-group>
      </xsl:for-each-group>
    </xsl:for-each>
  </table-body>
</table>

    </flow>
  </page-sequence>
</root>

t:\ftemp>type test.xml
<?xml version="1.0" encoding="UTF-8"?>
<table>
  <tgroup>
    <tbody>
      <row><entry>A</entry><entry>B</entry><entry>C</entry><entry>D</entry><entry>E</entry><entry>F</entry></row>
      <row><entry>A</entry><entry>G</entry><entry>H</entry><entry>I</entry><entry>J</entry><entry>K</entry></row>
      <row><entry>A</entry><entry>G</entry><entry>H</entry><entry>L</entry><entry>M</entry><entry>N</entry></row>
      <row><entry>A</entry><entry>G</entry><entry>O</entry><entry>P</entry><entry>M</entry><entry>Q</entry></row>
      <row><entry>A</entry><entry>G</entry><entry>R</entry><entry>S</entry><entry>T</entry><entry>Q</entry></row>
      <row><entry>A</entry><entry>G</entry><entry>V</entry><entry>S</entry><entry>W</entry><entry>X</entry></row>
      <row><entry>A</entry><entry>Y</entry><entry>Z</entry><entry>1</entry><entry>2</entry><entry>3</entry></row>
      <row><entry>A</entry><entry>Y</entry><entry>4</entry><entry>1</entry><entry>5</entry><entry>6</entry></row>
      <row><entry>A</entry><entry>Y</entry><entry>7</entry><entry>1</entry><entry>5</entry><entry>8</entry></row>
    </tbody>
  </tgroup>
</table>

<xsl:template match="@*|node()"><!--identity for all other nodes-->
  <xsl:copy>
    <xsl:apply-templates select="@*|node()"/>
  </xsl:copy>
</xsl:template>

</xsl:stylesheet>
t:\ftemp>rem Done!

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

Hi list,

I'm making a stylesheet that converts DITA
documents to XSL-FO. Usually a table is authored
with entry/@morerows attribute. But some table
has no @morerows attribute. My challenge is to
generate row-spanned table from this table automatically by stylesheet.

For your reference I uploaded sample PDF to Yahoo! Box.

http://yahoo.jp/box/B71Fo9

(To download the PDF, click "cc&c3c-c<c " button.)

It would help us help you to have the XML input
data of your table example.  You can post it as
clear text in your message and we can cut it out and create a file from it.

The first table is input table. It has no
@morerows attribute. The second result table is
desired output. The first column and second
column and third column has row spans.

Can someone give me an advice about how to implement this?

A brute force approach would be by counting the
number of rows that follow until the cell value
changes.  I suspect this can be done with a
straightforward XPath 2.0 expression, but I'm not
about to take the time to recreate the input data to test it.

Alternatively, one might be able to use nested
grouping for a more elegant approach.  Actually,
thinking about this, this might even be preferred.

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

Hi list,

I'm making a stylesheet that converts DITA
documents to XSL-FO. Usually a table is authored
with entry/@morerows attribute. But some table
has no @morerows attribute. My challenge is to
generate row-spanned table from this table automatically by stylesheet.

For your reference I uploaded sample PDF to Yahoo! Box.

http://yahoo.jp/box/B71Fo9

(To download the PDF, click "cc&c3c-c<c " button.)

It would help us help you to have the XML input
data of your table example.  You can post it as
clear text in your message and we can cut it out and create a file from it.

The first table is input table. It has no
@morerows attribute. The second result table is
desired output. The first column and second
column and third column has row spans.

Can someone give me an advice about how to implement this?

A brute force approach would be by counting the
number of rows that follow until the cell value
changes.  I suspect this can be done with a
straightforward XPath 2.0 expression, but I'm not
about to take the time to recreate the input data to test it.

Alternatively, one might be able to use nested
grouping for a more elegant approach.  Actually,
thinking about this, this might even be preferred.

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

A friend of mine just sent this out this morning, and I thought it
might be of interest to some people on this group.

----
This thread within the "blink-dev" discussion for Chrome's new
rendering engine ... examines the possibility of removing support for
XSLT from the browser. If so, Blink would be the first major browser
to remove support:
(https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/KZ0eaL-3vQY)

There is some discussion of usage on the web at large, but note Eric
Seidel's (of the Chrome team) comment from 4/23:

"My suspicion is that neither can be removed from the platform at this
time. But both are probably good opportunities for later removal or
replacement with JS-based polyfills. I expect removing the need to
ship libxslt as part of Chrome to be a small (but non-trivial) binary
size win."
(https://groups.google.com/a/chromium.org/d/msg/blink-dev/KZ0eaL-3vQY/6Yh4qSidA6AJ)
----

Perhaps if some people here know some resources to determine usage of
XSLT on the client, and/or compelling reasons to keep this
functionality, they could weigh in.

Chris Maloney

This isn't the first time I've seen this sort of thinking from browser developers, and it makes me mad and sad. Any time there's even a slight bump in the road for client-side XSLT support, the first thought that comes to mind is that they should simply dump support altogether. After all, if THEY'VE never used it, they can't imagine why anybody would... ugh.

~ Scott


-----Original Message-----
From: Chris Maloney [mailto:voldrani@xxxxxxxxx] 
Sent: Wednesday, April 24, 2013 9:13 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject:  Chrome/blink developers discussing removing XSLT support

A friend of mine just sent this out this morning, and I thought it might be of interest to some people on this group.

----
This thread within the "blink-dev" discussion for Chrome's new rendering engine ... examines the possibility of removing support for XSLT from the browser. If so, Blink would be the first major browser to remove support:
(https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/KZ0eaL-3vQY)

There is some discussion of usage on the web at large, but note Eric Seidel's (of the Chrome team) comment from 4/23:

"My suspicion is that neither can be removed from the platform at this time. But both are probably good opportunities for later removal or replacement with JS-based polyfills. I expect removing the need to ship libxslt as part of Chrome to be a small (but non-trivial) binary size win."
(https://groups.google.com/a/chromium.org/d/msg/blink-dev/KZ0eaL-3vQY/6Yh4qSidA6AJ)
----

Perhaps if some people here know some resources to determine usage of XSLT on the client, and/or compelling reasons to keep this functionality, they could weigh in.

Chris Maloney

I am downloading loading webpages and munging the markup.  I strip
off the HTML namespace as part of the munging process but now I have
a requirement to reconstitute the HTML.

Can I leave the html unnamespaced or is it ok or  necessary to just
stick in an xmlns="http://www.w3.org/1999/xhtml" (or some other)
declaration

That appears to be an html question not an xslt one, so this is a _very_
marginal question for this list.

If you are generating HTML 4 or earlier any xmlns attribute is invalid.
If you are generating HTML5 or later
xmlns="http://www.w3.org/1999/xhtml" is valid but ignored.

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

I am downloading loading webpages and munging the markup.  I strip
off the HTML namespace as part of the munging process but now I have
a requirement to reconstitute the HTML.

Can I leave the html unnamespaced or is it ok or  necessary to just
stick in an xmlns="http://www.w3.org/1999/xhtml" (or some other)
declaration

That appears to be an html question not an xslt one, so this is a _very_
marginal question for this list.

If you are generating HTML 4 or earlier any xmlns attribute is invalid.
If you are generating HTML5 or later
xmlns="http://www.w3.org/1999/xhtml" is valid but ignored.

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

 Well, no browser has its own support for XSLT 2.0 and theirs simply
can't compete with Saxon CE.

A logical conclusion for a browser vendor is to incorporate Saxon CE
in their product -- this will give them some cutting edge advantage
over the competition  while at the same time significantly enhancing
the functionality and usefulness of their browser.

Alas, I am not one of the browser vendors... but these people probably
can make logical conclusions?


On Wed, Apr 24, 2013 at 7:54 AM, Scott Trenda <Scott.Trenda@xxxxxxxx> wrote:
> This isn't the first time I've seen this sort of thinking from browser
developers, and it makes me mad and sad. Any time there's even a slight bump
in the road for client-side XSLT support, the first thought that comes to mind
is that they should simply dump support altogether. After all, if THEY'VE
never used it, they can't imagine why anybody would... ugh.
>
> ~ Scott
>



--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.

I am downloading loading webpages and munging the markup.  I strip off
the HTML namespace as part of the munging process but now I have a
requirement to reconstitute the HTML.

Can I leave the html unnamespaced or is it ok or  necessary to just
stick in an xmlns="http://www.w3.org/1999/xhtml" (or some other)
declaration

I am downloading loading webpages and munging the markup.  I strip off
the HTML namespace as part of the munging process but now I have a
requirement to reconstitute the HTML.

Can I leave the html unnamespaced or is it ok or  necessary to just
stick in an xmlns="http://www.w3.org/1999/xhtml" (or some other)
declaration

Yes, the example I sent does not make any sense after reading the spec
properly.

-----Original Message-----
From: Michael Kay [mailto:mike@xxxxxxxxxxxx]
Sent: Saturday, April 20, 2013 6:41 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re:  accumulators

Like xsl:key, accumulators apply to every document, but when you evaluate
the accumulator function, you get the value applicable to the context node.
In all your calls of the accumulator function, the context node is the root
of the principal source document.

Accumulators are strictly functional: the value is a function of the context
node. If you call the function twice and the context node is the same for
both calls, you will get the same answer.

Michael Kay
Saxonica


On 19 Apr 2013, at 22:04, Jakub Mal} wrote:

> Hi,
> I am fiddling with XSLT accumulators in the new version of Saxon.
> I first looked at the examples in the spec and thought that this might
> work (and output 01210), but it doesn't:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> 	xmlns:f="myf"	version="3.0">
>
> 	<xsl:accumulator name="f:my-var" as="xs:integer" initial-value="0" >
> 		<xsl:accumulator-rule match="f:inc" new-value="$value + 1"/>
> 		<xsl:accumulator-rule match="f:dec" new-value="$value - 1"/>
> 	</xsl:accumulator>
>
> 	<xsl:variable name="f:control-inc" as="element()*">
> 		<f:inc/>
> 	</xsl:variable>
> 	<xsl:variable name="f:control-dec" as="element()*">
> 		<f:dec/>
> 	</xsl:variable>
>
> 	<xsl:template match="/">
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-inc"/>
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-inc"/>
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-dec"/>
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-dec"/>
> 		<xsl:value-of select="f:my-var()" />
> 	</xsl:template>
> </xsl:stylesheet>
>
> So I read the spec and I guess I understand why.
> Accumulator rule is not triggered by calling apply-templates, it does
> not matter how many times the same node is processed, the value for
> the accumulator will be the same.
>
> Do accumulators work only for the nodes from the source document or
> also for nodes from documents loaded using doc() or document()?
>
> Jakub.

Yes, the example I sent does not make any sense after reading the spec
properly.

-----Original Message-----
From: Michael Kay [mailto:mike@xxxxxxxxxxxx]
Sent: Saturday, April 20, 2013 6:41 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re:  accumulators

Like xsl:key, accumulators apply to every document, but when you evaluate
the accumulator function, you get the value applicable to the context node.
In all your calls of the accumulator function, the context node is the root
of the principal source document.

Accumulators are strictly functional: the value is a function of the context
node. If you call the function twice and the context node is the same for
both calls, you will get the same answer.

Michael Kay
Saxonica


On 19 Apr 2013, at 22:04, Jakub Mal} wrote:

> Hi,
> I am fiddling with XSLT accumulators in the new version of Saxon.
> I first looked at the examples in the spec and thought that this might
> work (and output 01210), but it doesn't:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> 	xmlns:f="myf"	version="3.0">
>
> 	<xsl:accumulator name="f:my-var" as="xs:integer" initial-value="0" >
> 		<xsl:accumulator-rule match="f:inc" new-value="$value + 1"/>
> 		<xsl:accumulator-rule match="f:dec" new-value="$value - 1"/>
> 	</xsl:accumulator>
>
> 	<xsl:variable name="f:control-inc" as="element()*">
> 		<f:inc/>
> 	</xsl:variable>
> 	<xsl:variable name="f:control-dec" as="element()*">
> 		<f:dec/>
> 	</xsl:variable>
>
> 	<xsl:template match="/">
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-inc"/>
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-inc"/>
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-dec"/>
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-dec"/>
> 		<xsl:value-of select="f:my-var()" />
> 	</xsl:template>
> </xsl:stylesheet>
>
> So I read the spec and I guess I understand why.
> Accumulator rule is not triggered by calling apply-templates, it does
> not matter how many times the same node is processed, the value for
> the accumulator will be the same.
>
> Do accumulators work only for the nodes from the source document or
> also for nodes from documents loaded using doc() or document()?
>
> Jakub.

Like xsl:key, accumulators apply to every document, but when you evaluate the
accumulator function, you get the value applicable to the context node. In all
your calls of the accumulator function, the context node is the root of the
principal source document.

Accumulators are strictly functional: the value is a function of the context
node. If you call the function twice and the context node is the same for both
calls, you will get the same answer.

Michael Kay
Saxonica


On 19 Apr 2013, at 22:04, Jakub Mal} wrote:

> Hi,
> I am fiddling with XSLT accumulators in the new version of Saxon.
> I first looked at the examples in the spec and thought that this might work
> (and output 01210), but it doesn't:
>
> <?xml version="1.0" encoding="UTF-8"?>
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> 	xmlns:f="myf"	version="3.0">
>
> 	<xsl:accumulator name="f:my-var" as="xs:integer" initial-value="0" >
> 		<xsl:accumulator-rule match="f:inc" new-value="$value + 1"/>
> 		<xsl:accumulator-rule match="f:dec" new-value="$value - 1"/>
> 	</xsl:accumulator>
>
> 	<xsl:variable name="f:control-inc" as="element()*">
> 		<f:inc/>
> 	</xsl:variable>
> 	<xsl:variable name="f:control-dec" as="element()*">
> 		<f:dec/>
> 	</xsl:variable>
>
> 	<xsl:template match="/">
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-inc"/>
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-inc"/>
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-dec"/>
> 		<xsl:value-of select="f:my-var()" />
> 		<xsl:apply-templates select="$f:control-dec"/>
> 		<xsl:value-of select="f:my-var()" />
> 	</xsl:template>
> </xsl:stylesheet>
>
> So I read the spec and I guess I understand why.
> Accumulator rule is not triggered by calling apply-templates, it does not
> matter how many times the same node is processed, the value for the
> accumulator will be the same.
>
> Do accumulators work only for the nodes from the source document or also
for
> nodes from documents loaded using doc() or document()?
>
> Jakub.

Hi, 
I am fiddling with XSLT accumulators in the new version of Saxon. 
I first looked at the examples in the spec and thought that this might work
(and output 01210), but it doesn't:

<?xml version="1.0" encoding="UTF-8"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:f="myf"	version="3.0">

	<xsl:accumulator name="f:my-var" as="xs:integer" initial-value="0" >
		<xsl:accumulator-rule match="f:inc" new-value="$value + 1"/>
		<xsl:accumulator-rule match="f:dec" new-value="$value - 1"/>
	</xsl:accumulator>
	
	<xsl:variable name="f:control-inc" as="element()*">
		<f:inc/>
	</xsl:variable>
	<xsl:variable name="f:control-dec" as="element()*">
		<f:dec/>
	</xsl:variable>
	
	<xsl:template match="/">
		<xsl:value-of select="f:my-var()" />
		<xsl:apply-templates select="$f:control-inc"/>
		<xsl:value-of select="f:my-var()" />
		<xsl:apply-templates select="$f:control-inc"/>
		<xsl:value-of select="f:my-var()" />
		<xsl:apply-templates select="$f:control-dec"/>
		<xsl:value-of select="f:my-var()" />
		<xsl:apply-templates select="$f:control-dec"/>
		<xsl:value-of select="f:my-var()" />
	</xsl:template>
</xsl:stylesheet>

So I read the spec and I guess I understand why. 
Accumulator rule is not triggered by calling apply-templates, it does not
matter how many times the same node is processed, the value for the
accumulator will be the same. 

Do accumulators work only for the nodes from the source document or also for
nodes from documents loaded using doc() or document()?  

Jakub.

Hi, 
I am fiddling with XSLT accumulators in the new version of Saxon. 
I first looked at the examples in the spec and thought that this might work
(and output 01210), but it doesn't:

<?xml version="1.0" encoding="UTF-8"?>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:f="myf"	version="3.0">

	<xsl:accumulator name="f:my-var" as="xs:integer" initial-value="0" >
		<xsl:accumulator-rule match="f:inc" new-value="$value + 1"/>
		<xsl:accumulator-rule match="f:dec" new-value="$value - 1"/>
	</xsl:accumulator>
	
	<xsl:variable name="f:control-inc" as="element()*">
		<f:inc/>
	</xsl:variable>
	<xsl:variable name="f:control-dec" as="element()*">
		<f:dec/>
	</xsl:variable>
	
	<xsl:template match="/">
		<xsl:value-of select="f:my-var()" />
		<xsl:apply-templates select="$f:control-inc"/>
		<xsl:value-of select="f:my-var()" />
		<xsl:apply-templates select="$f:control-inc"/>
		<xsl:value-of select="f:my-var()" />
		<xsl:apply-templates select="$f:control-dec"/>
		<xsl:value-of select="f:my-var()" />
		<xsl:apply-templates select="$f:control-dec"/>
		<xsl:value-of select="f:my-var()" />
	</xsl:template>
</xsl:stylesheet>

So I read the spec and I guess I understand why. 
Accumulator rule is not triggered by calling apply-templates, it does not
matter how many times the same node is processed, the value for the
accumulator will be the same. 

Do accumulators work only for the nodes from the source document or also for
nodes from documents loaded using doc() or document()?  

Jakub.

For some reason when using mode the indentation and line breaks are all removed:

This is the initiater:
<xsl:template match="/" mode="run2">

<nitf version="-//IPTC//DTD NITF 3.2//EN" change.date="October 10, 2003" change.time="19:30"
baselang="no-NO">
<!-- Call template header -->
<xsl:call-template name="header" />

            <body>
                <xsl:call-template name="body3"/>
            </body>
        </nitf>
    </xsl:template>

Output:
<?xml version="1.0" encoding="UTF-8"?><nitf xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ckbk="http://my.safaribooksonline.com/book/xml/0596009747/dates-and-times/" version="-//IPTC//DTD NITF 3.2//EN" change.date="October 10, 2003" change.time="19:30" baselang="no-NO"><head><title>Langoddstips uke 16</title><meta name="timestamp" content="2013.4.18 12:52:50"/>

I have this in the "global" area of xslt:
<xsl:output method="xml" indent="yes" encoding="ISO-8859-1" name="xml" />

Any suggestions?

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

For some reason when using mode the indentation and line breaks are all removed:

This is the initiater:
<xsl:template match="/" mode="run2">

<nitf version="-//IPTC//DTD NITF 3.2//EN" change.date="October 10, 2003" change.time="19:30"
baselang="no-NO">
<!-- Call template header -->
<xsl:call-template name="header" />

            <body>
                <xsl:call-template name="body3"/>
            </body>
        </nitf>
    </xsl:template>

Output:
<?xml version="1.0" encoding="UTF-8"?><nitf xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:ckbk="http://my.safaribooksonline.com/book/xml/0596009747/dates-and-times/" version="-//IPTC//DTD NITF 3.2//EN" change.date="October 10, 2003" change.time="19:30" baselang="no-NO"><head><title>Langoddstips uke 16</title><meta name="timestamp" content="2013.4.18 12:52:50"/>

I have this in the "global" area of xslt:
<xsl:output method="xml" indent="yes" encoding="ISO-8859-1" name="xml" />

Any suggestions?

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

Hey guys,

I have an xml file with many p tags --

        INPUT --
...
        I want all the p tags which are above inline img class to be
replaced by <p channel="y.com"> and it will look like
...
        I dont want to replace any other normal p tags.So, in this
particular example find and replace will happen at two places.

I used this code,but it is not working.Please advise.Thanks.

T:\ftemp>type arkle.xml
<?xml version="1.0" encoding="UTF-8"?>
<test>
  <p>
              <inline-img class="full">
                <web-main-photo>
                  <photo src="http://yahoo.com/test.jpg"/>
                </web-main-photo>
                <data>
                  <br/>
                  <caption>
                    <p> (Nick Wass/Associated Press)</p>
                  </caption>
                </data>
              </inline-img>
            </p>
            <p>this is content </p>
            <p>After missing the past three games with an injured left
leg, Martin Erat will return to the <a href="/blog/">Capitals</a>'
lineup Saturday night at Verizon Center against the Tampa Bay
Lightning.</p>
            <p>Erat, 31, suffered the injury on April 6 at Florida
when Panthers defenseman Erik Gudbranson delivered a late hit from
behind that sent the veteran winger awkwardly into the boards. He
avoided significant harm, though, and after five consecutive days of
skating Erat said he's prepared to get back to game action.</p>
        <p>
              <inline-img class="full">
                <web-main-photo>
                  <photo src="http://yahoo.com/test.jpg"/>
                </web-main-photo>
                <data>
                  <br/>
                  <caption>
                    <p> (Nick Wass/Associated Press)</p>
                  </caption>
                </data>
              </inline-img>
            </p>
            <p>"Feeling good. Feels better every day, I'm pretty much
ready to go," Erat said, adding that while he would have much rather
been playing games with his new team the time to take part in practice
and watch the system work from above should help him make a smooth
transition.</p>
</test>

T:\ftemp>call xslt arkle.xml arkle.xsl
<?xml version="1.0" encoding="utf-8"?><test>
  <p channel="y">
              <inline-img class="full">
                <web-main-photo>
                  <photo src="http://yahoo.com/test.jpg"/>
                </web-main-photo>
                <data>
                  <br/>
                  <caption>
                    <p> (Nick Wass/Associated Press)</p>
                  </caption>
                </data>
              </inline-img>
            </p>
            <p>this is content </p>
            <p>After missing the past three games with an injured left
leg, Martin Erat will return to the <a href="/blog/">Capitals</a>'
lineup Saturday night at Verizon Center against the Tampa Bay
Lightning.</p>
            <p>Erat, 31, suffered the injury on April 6 at Florida
when Panthers defenseman Erik Gudbranson delivered a late hit from
behind that sent the veteran winger awkwardly into the boards. He
avoided significant harm, though, and after five consecutive days of
skating Erat said he's prepared to get back to game action.</p>
        <p channel="y">
              <inline-img class="full">
                <web-main-photo>
                  <photo src="http://yahoo.com/test.jpg"/>
                </web-main-photo>
                <data>
                  <br/>
                  <caption>
                    <p> (Nick Wass/Associated Press)</p>
                  </caption>
                </data>
              </inline-img>
            </p>
            <p>"Feeling good. Feels better every day, I'm pretty much
ready to go," Erat said, adding that while he would have much rather
been playing games with his new team the time to take part in practice
and watch the system work from above should help him make a smooth
transition.</p>
</test>
T:\ftemp>type arkle.xsl
<?xml version="1.0" encoding="US-ASCII"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                version="1.0">

<xsl:template match="p[inline-img]">
  <p channel="y">
    <xsl:apply-templates/>
  </p>
</xsl:template>

<xsl:template match="@*|node()"><!--identity for all other nodes-->
  <xsl:copy>
    <xsl:apply-templates select="@*|node()"/>
  </xsl:copy>
</xsl:template>

</xsl:stylesheet>
T:\ftemp>rem Done!

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

        Hey guys,

        I have an xml file with many p tags --

        INPUT --

        <p>
              <inline-img class="full">
                <web-main-photo>
                  <photo src="http://yahoo.com/test.jpg"/>
                </web-main-photo>
                <data>
                  <br/>
                  <caption>
                    <p> (Nick Wass/Associated Press)</p>
                  </caption>
                </data>
              </inline-img>
            </p>
            <p>this is content </p>
            <p>After missing the past three games with an injured left
leg, Martin Erat will return to the <a href="/blog/">Capitals</a>'
lineup Saturday night at Verizon Center against the Tampa Bay
Lightning.</p>
            <p>Erat, 31, suffered the injury on April 6 at Florida
when Panthers defenseman Erik Gudbranson delivered a late hit from
behind that sent the veteran winger awkwardly into the boards. He
avoided significant harm, though, and after five consecutive days of
skating Erat said he's prepared to get back to game action.</p>
        <p>
              <inline-img class="full">
                <web-main-photo>
                  <photo src="http://yahoo.com/test.jpg"/>
                </web-main-photo>
                <data>
                  <br/>
                  <caption>
                    <p> (Nick Wass/Associated Press)</p>
                  </caption>
                </data>
              </inline-img>
            </p>
            <p>"Feeling good. Feels better every day, I'm pretty much
ready to go," Erat said, adding that while he would have much rather
been playing games with his new team the time to take part in practice
and watch the system work from above should help him make a smooth
transition.</p>


        INPUT ENDS HERE

        I want all the p tags which are above inline img class to be
replaced by <p channel="y.com"> and it will look like

        <p channel="y.com">
          <inline-img class="full">
                <web-main-photo>
                  <photo src="http://yahoo.com/test.jpg"/>
                </web-main-photo>
                <data>
                  <br/>
                  <caption>
                    <p> (Nick Wass/Associated Press)</p>
                  </caption>
                </data>
              </inline-img>
            </p>

        I dont want to replace any other normal p tags.So, in this
particular example find and replace will happen at two places.

        I used this code,but it is not working.Please advise.Thanks.

        XSLT CODE using xslt 1.0




 <?xml version="1.0"?>
        <xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
            <xsl:template match="/">
            <component>

                    <p>
                        <xsl:call-template name="replace-text">
                                <xsl:with-param name="text"
select="/item/content" />
                                <xsl:with-param name="replace"
select="'&lt;p&gt;&lt;inline-img class='" />
                                <xsl:with-param name="by"
select="'&lt;p channel="y.com"&gt;&lt;inline-img class='" />
                        </xsl:call-template>
                    </p>

            </component>
        </xsl:template>

        <xsl:template name="replace-text">
           <xsl:param name="text"/>
           <xsl:param name="replace" />
           <xsl:param name="by" />

           <xsl:choose>
           <xsl:when test="contains($text, $replace)">
              <xsl:value-of select="substring-before($text, $replace)"/>
              <xsl:value-of select="$by" disable-output-escaping="yes"/>
              <xsl:call-template name="replace-text">
                 <xsl:with-param name="text"
select="substring-after($text, $replace)"/>
                 <xsl:with-param name="replace" select="$replace" />
                 <xsl:with-param name="by" select="$by" />
              </xsl:call-template>
           </xsl:when>
           <xsl:otherwise>
              <xsl:value-of select="$text"/>
           </xsl:otherwise>
           </xsl:choose>
        </xsl:template>
        </xsl:stylesheet>

    Thanks so much for your help.I really appreciate it.

strip513,

Did you know that cross-posting is evil?

See this answer to your identical question asked at SO:

http://stackoverflow.com/a/16096705/36305



On Thu, Apr 18, 2013 at 8:02 PM, G. Ken Holman
<gkholman@xxxxxxxxxxxxxxxxxxxx> wrote:
> At 2013-04-18 22:38 -0400, strip513 . wrote:
>>
>>         Hey guys,
>>
>>         I have an xml file with many p tags --
>>
>>         INPUT --
>> ...
>>
>>         I want all the p tags which are above inline img class to be
>> replaced by <p channel="y.com"> and it will look like
>> ...
>>
>>         I dont want to replace any other normal p tags.So, in this
>> particular example find and replace will happen at two places.
>>
>>         I used this code,but it is not working.Please advise.Thanks.
>
>
> I advise you to look at XSLT differently, so I'm glad you posted.  You are
> treating XSLT imperatively, in a manner like Java or C or Python, and not
> taking advantage of what XSLT can do for you.  And you are trying to create
> angle brackets in your strings, which is entirely inappropriate for XSLT.
>
> Consider the working solution below that does what you ask.  It is written
> declaratively and it looks at the input as a tree of nodes, not as a string
> of angle brackets.  I declare in my stylesheet what I want the output to
> look like for a given input element.  I've characterized what is special
> about <p> element nodes that need to be written out differently, otherwise,
> all element nodes are simply copied to the result tree as they are found in
> the input tree.
>
> You need to approach solutions in a manner appropriate to the processing
> model (declarative) and data model (nodes) of XSLT.  Using purely imperative
> approaches and putting angle strings will not help you and will hinder your
> use of the language.
>
> XSLT is built for XML and with XML, it is not a language that simply
> supports XML from function calls.
>
> I hope you find this helpful.
>
> . . . . . . . Ken
>
>
> T:\ftemp>type arkle.xml
> <?xml version="1.0" encoding="UTF-8"?>
> <test>
>
>   <p>
>               <inline-img class="full">
>                 <web-main-photo>
>                   <photo src="http://yahoo.com/test.jpg"/>
>                 </web-main-photo>
>                 <data>
>                   <br/>
>                   <caption>
>                     <p> (Nick Wass/Associated Press)</p>
>                   </caption>
>                 </data>
>               </inline-img>
>             </p>
>             <p>this is content </p>
>             <p>After missing the past three games with an injured left
> leg, Martin Erat will return to the <a href="/blog/">Capitals</a>'
> lineup Saturday night at Verizon Center against the Tampa Bay
> Lightning.</p>
>             <p>Erat, 31, suffered the injury on April 6 at Florida
> when Panthers defenseman Erik Gudbranson delivered a late hit from
> behind that sent the veteran winger awkwardly into the boards. He
> avoided significant harm, though, and after five consecutive days of
> skating Erat said he's prepared to get back to game action.</p>
>         <p>
>               <inline-img class="full">
>                 <web-main-photo>
>                   <photo src="http://yahoo.com/test.jpg"/>
>                 </web-main-photo>
>                 <data>
>                   <br/>
>                   <caption>
>                     <p> (Nick Wass/Associated Press)</p>
>                   </caption>
>                 </data>
>               </inline-img>
>             </p>
>             <p>"Feeling good. Feels better every day, I'm pretty much
> ready to go," Erat said, adding that while he would have much rather
> been playing games with his new team the time to take part in practice
> and watch the system work from above should help him make a smooth
> transition.</p>
> </test>
>
> T:\ftemp>call xslt arkle.xml arkle.xsl
> <?xml version="1.0" encoding="utf-8"?><test>
>   <p channel="y">
>
>               <inline-img class="full">
>                 <web-main-photo>
>                   <photo src="http://yahoo.com/test.jpg"/>
>                 </web-main-photo>
>                 <data>
>                   <br/>
>                   <caption>
>                     <p> (Nick Wass/Associated Press)</p>
>                   </caption>
>                 </data>
>               </inline-img>
>             </p>
>             <p>this is content </p>
>             <p>After missing the past three games with an injured left
> leg, Martin Erat will return to the <a href="/blog/">Capitals</a>'
> lineup Saturday night at Verizon Center against the Tampa Bay
> Lightning.</p>
>             <p>Erat, 31, suffered the injury on April 6 at Florida
> when Panthers defenseman Erik Gudbranson delivered a late hit from
> behind that sent the veteran winger awkwardly into the boards. He
> avoided significant harm, though, and after five consecutive days of
> skating Erat said he's prepared to get back to game action.</p>
>         <p channel="y">
>
>               <inline-img class="full">
>                 <web-main-photo>
>                   <photo src="http://yahoo.com/test.jpg"/>
>                 </web-main-photo>
>                 <data>
>                   <br/>
>                   <caption>
>                     <p> (Nick Wass/Associated Press)</p>
>                   </caption>
>                 </data>
>               </inline-img>
>             </p>
>             <p>"Feeling good. Feels better every day, I'm pretty much
> ready to go," Erat said, adding that while he would have much rather
> been playing games with his new team the time to take part in practice
> and watch the system work from above should help him make a smooth
> transition.</p>
> </test>
> T:\ftemp>type arkle.xsl
> <?xml version="1.0" encoding="US-ASCII"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 version="1.0">
>
> <xsl:template match="p[inline-img]">
>   <p channel="y">
>     <xsl:apply-templates/>
>   </p>
> </xsl:template>
>
> <xsl:template match="@*|node()"><!--identity for all other nodes-->
>   <xsl:copy>
>     <xsl:apply-templates select="@*|node()"/>
>   </xsl:copy>
> </xsl:template>
>
> </xsl:stylesheet>
> T:\ftemp>rem Done!
>
>
> --
> Contact us for world-wide XML consulting and instructor-led training |
> Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
> Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
> G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
> Google+ profile: https://plus.google.com/116832879756988317389/about |
> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |
>



-- 
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.

Hi,

For some reason when using mode the indentation and line breaks are all
removed:
This is the initiater:
<xsl:template match="/" mode="run2">

        <nitf version="-//IPTC//DTD NITF 3.2//EN" change.date="October 10,
2003" change.time="19:30"
            baselang="no-NO">
            <!-- Call template header -->
            <xsl:call-template name="header" />

            <body>
                <xsl:call-template name="body3"/>
            </body>
        </nitf>
    </xsl:template>

Output:
<?xml version="1.0" encoding="UTF-8"?><nitf
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:ckbk="http://my.safaribooksonline.com/book/xml/0596009747/dates-and-tim
es/" version="-//IPTC//DTD NITF 3.2//EN" change.date="October 10, 2003"
change.time="19:30" baselang="no-NO"><head><title>Langoddstips uke
16</title><meta name="timestamp" content="2013.4.18 12:52:50"/>

I have this in the "global" area of xslt:
<xsl:output method="xml" indent="yes" encoding="ISO-8859-1" name="xml" />

Any suggestions?

Best regards,

Trond Husx

Just been burnt by the fact that XSLT defaults to html output and
therefore does not emit well formed xml (e.g does not close img tags
 even if you tell it to) upon seeing a root element of html - EVEN if
 that root element is not in the html/xhtml namespace.

This rule has been in place since XSLT 1. Note you only get the html
output method if the top level element is in _no_ namespace. If it is in
the xhtml namespace then yiou get the xhtml method (or the xml method
if xslt 1 compatibility is in force).

If producing html it is important not to use /> when generating html as
(prior to HTML5)
<meta.../>
is a syntax error in html.

Just been burnt by the fact that XSLT defaults to html output and
therefore does not emit well formed xml (e.g does not close img tags
even if you tell it to) upon seeing a root element of html - EVEN if
that root element is not in the html/xhtml namespace.

If the first hypothesis is correct, it will explain that
"self::node()[starts-with(name,'tdown')]" does not match while
"child::node()[starts-with(name,'tdown')]" or
"*[starts-with(name,'tdown')]" will probably match. All based on the

If the first hypothesis is correct, it will explain that
"self::node()[starts-with(name,'tdown')]" does not match while
"child::node()[starts-with(name,'tdown')]" or
"*[starts-with(name,'tdown')]" will probably match. All based on the

XSL:
<xsl:template match="entry/sum">
   ...
   <xsl:for-each select=".[starts-with(name,'tdown')]">
   ...
   </xsl:for-each>
   ...
</xsl:template>

Hello,

I have a stylesheet which works correct if I use:

.[predicate]

but I get an warning/error from the transformer saying:

'..[predicate]' or '.[predicate]' is illegal syntax.  Use
'self::node()[predicate]' instead.
And this spams the (tomcat) log files that way that they get unusable!
Therefore I would like to get rid of this
warning/error message. BUT if I do as recommended and use
'self::node()[predicate], the transformation results
in no match?!

The transformer I use is Xalan Java 2.7.0. Is there an easy way to suppress
the warning/error, or to change the
statement to be legal (while producing the same matches).

Code looks something like this:
XML:
<sum>
  <tdownA>0.7</tdownA>
  <tdownB>0.1</tdownB>
</sum>

XSL:
<xsl:template match="entry/sum">
  ...
  <xsl:for-each select=".[starts-with(name,'tdown')]">
  ...
  </xsl:for-each>
  ...
</xsl:template>

(and YES I should/could change the template match condition to be
match="entry" and the for-each to be
select="sum[starts-with(name,'tdown')]", but this would break a lot other
surrounding logic, which I don't want
to touch!)

Any help would be appreciated!

Cheers,
Raimund

Hello,

I have a stylesheet which works correct if I use:

.[predicate]

but I get an warning/error from the transformer saying:

XSL Working Group,
Greetings. Previous research and projects into XSLT and SPARQL include Topia
(http://www.telin.nl/index.cfm?language=en&project=Topia) from the research of
Jacco Van Ossenbruggen, Lynda Hardman and Lloyd Rutledge, RDF Twig
(http://norman.walsh.name/2004/projects/rdftwig) by Norman Walsh, and
XSLT+SPARQL (http://berrueta.net/research/xsltsparql) by Diego Berrueta, Jose
E. Labra, and Ivan Herman.
SPARQL 1.1 (http://www.w3.org/TR/sparql11-overview/) includes the query forms
of SELECT, CONSTRUCT, ASK and DESCRIBE and each query form would be useful to
have, in terms of XSLT expressiveness and logic, with regard to querying local
and remote data stores including for URI passed to XSLT templates as
parameters.
I was wondering whether there was any interest in discussing enhancing SPARQL
in XSLT or discussing the requirements of a specification standardizing an
extension to XSLT for SPARQL 1.1?
 Kind regards,
 Adam Sobieski

Now fixed.

https://saxonica.plan.io/issues/1731

Thanks Bjoern and Octavian.

Michael Kay
Saxonica

On 10 Apr 2013, at 14:57, Octavian Nadolu wrote:

> Hello,
>
> The problem can be reproduced in oXygen 14.2 if schema-based validation
(-val) is enabled, the XML Schema version is set to 1.1 (-xsdversion) and the
'assertions can see comments' option is disabled.
> To resolve the problem you can enable the 'assertions can see comments'
option from the oXygen preferences, 'XML / XML Parser / XML Schema' options
page or you can set the default XML Schema version to 1.0, from the same
options page.
>
> This behavior can be reproduced also by running the transformation with
Saxon from the command line, with the following parameters:
> java -jar saxon9ee.jar test.xml -xsl:test.xsl -config:saxonCfg.xml
>
> ------- saxonCfg.xml--------------
> <configuration edition="EE" xmlns="http://saxon.sf.net/ns/configuration">
>    <xsd version="1.1" assertionsCanSeeComments="false"/>
>    <global schemaValidation="lax"/>
>    <xslt schemaAware="true">
>        <extensionElement/>
>    </xslt>
> </configuration>
> -------------------------------------------
>
> Regards,
> Octavian
> ---------------
> Octavian Nadolu
> <oXygen/> XML Editor
> http://www.oxygenxml.com
>
> On 10.04.2013 14:42, Michael Kay wrote:
>> We've tried this out on oXygen 14.2 and we're unable to reproduce the
problem.
>>
>> We can try it again perhaps with a specific stylesheet, source document,
and schema.
>>
>> Michael Kay
>> Saxonica
>>
>>
>> On 10 Apr 2013, at 09:15, bjoern.duenckel@xxxxxxxxxxxxxxxxxxx wrote:
>>
>>>> I'm always a bit reticent about discussing product-specific issues on =
>>>> this list - I like to be helpful to users and I don't mind doing it in =
>>>> public, but I'm conscious that not everyone on the list is interested. =
>>>> There's a Saxon specific forum athttp://saxonica.plan.io  which you are
=
>>>> welcome to use.
>>> Thanks for the advice!
>>> I will use the forum for Saxon realted issues in the future.
>>>
>>>> I can't see any obvious reason for this behaviour. Schema validation per
=
>>>> se shouldn't lose the comments, although it ignores them. How are you =
>>>> invoking the transformation?
>>> I used an oXygen transformation scenario to invoke the transformation:
>>>
>>>   oXygen XML Editor 14.2, build 2013030817
>>>   Transformer: Saxon-EE 9.4.0.6
>>>
>>>
>>> Regards
>>>
>>> Bjvrn D|nckel.

Now fixed.

https://saxonica.plan.io/issues/1731

Thanks Bjoern and Octavian.

Michael Kay
Saxonica

On 10 Apr 2013, at 14:57, Octavian Nadolu wrote:

> Hello,
>
> The problem can be reproduced in oXygen 14.2 if schema-based validation
(-val) is enabled, the XML Schema version is set to 1.1 (-xsdversion) and the
'assertions can see comments' option is disabled.
> To resolve the problem you can enable the 'assertions can see comments'
option from the oXygen preferences, 'XML / XML Parser / XML Schema' options
page or you can set the default XML Schema version to 1.0, from the same
options page.
>
> This behavior can be reproduced also by running the transformation with
Saxon from the command line, with the following parameters:
> java -jar saxon9ee.jar test.xml -xsl:test.xsl -config:saxonCfg.xml
>
> ------- saxonCfg.xml--------------
> <configuration edition="EE" xmlns="http://saxon.sf.net/ns/configuration">
>    <xsd version="1.1" assertionsCanSeeComments="false"/>
>    <global schemaValidation="lax"/>
>    <xslt schemaAware="true">
>        <extensionElement/>
>    </xslt>
> </configuration>
> -------------------------------------------
>
> Regards,
> Octavian
> ---------------
> Octavian Nadolu
> <oXygen/> XML Editor
> http://www.oxygenxml.com
>
> On 10.04.2013 14:42, Michael Kay wrote:
>> We've tried this out on oXygen 14.2 and we're unable to reproduce the
problem.
>>
>> We can try it again perhaps with a specific stylesheet, source document,
and schema.
>>
>> Michael Kay
>> Saxonica
>>
>>
>> On 10 Apr 2013, at 09:15, bjoern.duenckel@xxxxxxxxxxxxxxxxxxx wrote:
>>
>>>> I'm always a bit reticent about discussing product-specific issues on =
>>>> this list - I like to be helpful to users and I don't mind doing it in =
>>>> public, but I'm conscious that not everyone on the list is interested. =
>>>> There's a Saxon specific forum athttp://saxonica.plan.io  which you are
=
>>>> welcome to use.
>>> Thanks for the advice!
>>> I will use the forum for Saxon realted issues in the future.
>>>
>>>> I can't see any obvious reason for this behaviour. Schema validation per
=
>>>> se shouldn't lose the comments, although it ignores them. How are you =
>>>> invoking the transformation?
>>> I used an oXygen transformation scenario to invoke the transformation:
>>>
>>>   oXygen XML Editor 14.2, build 2013030817
>>>   Transformer: Saxon-EE 9.4.0.6
>>>
>>>
>>> Regards
>>>
>>> Bjvrn D|nckel.

------- saxonCfg.xml--------------
<configuration edition="EE" xmlns="http://saxon.sf.net/ns/configuration">
    <xsd version="1.1" assertionsCanSeeComments="false"/>
    <global schemaValidation="lax"/>
    <xslt schemaAware="true">
        <extensionElement/>
    </xslt>
</configuration>
-------------------------------------------

Regards,
Octavian
---------------
Octavian Nadolu
<oXygen/> XML Editor
http://www.oxygenxml.com

We've tried this out on oXygen 14.2 and we're unable to reproduce the problem.

We can try it again perhaps with a specific stylesheet, source document, and schema.

Michael Kay
Saxonica

On 10 Apr 2013, at 09:15, bjoern.duenckel@xxxxxxxxxxxxxxxxxxx wrote:

I'm always a bit reticent about discussing product-specific issues on =
this list - I like to be helpful to users and I don't mind doing it in =
public, but I'm conscious that not everyone on the list is interested. =
There's a Saxon specific forum athttp://saxonica.plan.io  which you are =
welcome to use.

Thanks for the advice!
I will use the forum for Saxon realted issues in the future.

I can't see any obvious reason for this behaviour. Schema validation per =
se shouldn't lose the comments, although it ignores them. How are you =
invoking the transformation?

I used an oXygen transformation scenario to invoke the transformation:

   oXygen XML Editor 14.2, build 2013030817
   Transformer: Saxon-EE 9.4.0.6

Regards

Bjvrn D|nckel.

------- saxonCfg.xml--------------
<configuration edition="EE" xmlns="http://saxon.sf.net/ns/configuration">
    <xsd version="1.1" assertionsCanSeeComments="false"/>
    <global schemaValidation="lax"/>
    <xslt schemaAware="true">
        <extensionElement/>
    </xslt>
</configuration>
-------------------------------------------

Regards,
Octavian
---------------
Octavian Nadolu
<oXygen/> XML Editor
http://www.oxygenxml.com

We've tried this out on oXygen 14.2 and we're unable to reproduce the problem.

We can try it again perhaps with a specific stylesheet, source document, and schema.

Michael Kay
Saxonica

On 10 Apr 2013, at 09:15, bjoern.duenckel@xxxxxxxxxxxxxxxxxxx wrote:

I'm always a bit reticent about discussing product-specific issues on =
this list - I like to be helpful to users and I don't mind doing it in =
public, but I'm conscious that not everyone on the list is interested. =
There's a Saxon specific forum athttp://saxonica.plan.io  which you are =
welcome to use.

Thanks for the advice!
I will use the forum for Saxon realted issues in the future.

I can't see any obvious reason for this behaviour. Schema validation per =
se shouldn't lose the comments, although it ignores them. How are you =
invoking the transformation?

I used an oXygen transformation scenario to invoke the transformation:

   oXygen XML Editor 14.2, build 2013030817
   Transformer: Saxon-EE 9.4.0.6

Regards

Bjvrn D|nckel.

OK, many thanks. It looks as if filtering out comments from the tree view that
is seen by assertions is having the unintended side-effect of filtering them
out from the validation output. We'll look into it.

Michael Kay
Saxonica


On 10 Apr 2013, at 14:57, Octavian Nadolu wrote:

> Hello,
>
> The problem can be reproduced in oXygen 14.2 if schema-based validation
(-val) is enabled, the XML Schema version is set to 1.1 (-xsdversion) and the
'assertions can see comments' option is disabled.
> To resolve the problem you can enable the 'assertions can see comments'
option from the oXygen preferences, 'XML / XML Parser / XML Schema' options
page or you can set the default XML Schema version to 1.0, from the same
options page.
>
> This behavior can be reproduced also by running the transformation with
Saxon from the command line, with the following parameters:
> java -jar saxon9ee.jar test.xml -xsl:test.xsl -config:saxonCfg.xml
>
> ------- saxonCfg.xml--------------
> <configuration edition="EE" xmlns="http://saxon.sf.net/ns/configuration">
>    <xsd version="1.1" assertionsCanSeeComments="false"/>
>    <global schemaValidation="lax"/>
>    <xslt schemaAware="true">
>        <extensionElement/>
>    </xslt>
> </configuration>
> -------------------------------------------
>
> Regards,
> Octavian
> ---------------
> Octavian Nadolu
> <oXygen/> XML Editor
> http://www.oxygenxml.com
>
> On 10.04.2013 14:42, Michael Kay wrote:
>> We've tried this out on oXygen 14.2 and we're unable to reproduce the
problem.
>>
>> We can try it again perhaps with a specific stylesheet, source document,
and schema.
>>
>> Michael Kay
>> Saxonica
>>
>>
>> On 10 Apr 2013, at 09:15, bjoern.duenckel@xxxxxxxxxxxxxxxxxxx wrote:
>>
>>>> I'm always a bit reticent about discussing product-specific issues on =
>>>> this list - I like to be helpful to users and I don't mind doing it in =
>>>> public, but I'm conscious that not everyone on the list is interested. =
>>>> There's a Saxon specific forum athttp://saxonica.plan.io  which you are
=
>>>> welcome to use.
>>> Thanks for the advice!
>>> I will use the forum for Saxon realted issues in the future.
>>>
>>>> I can't see any obvious reason for this behaviour. Schema validation per
=
>>>> se shouldn't lose the comments, although it ignores them. How are you =
>>>> invoking the transformation?
>>> I used an oXygen transformation scenario to invoke the transformation:
>>>
>>>   oXygen XML Editor 14.2, build 2013030817
>>>   Transformer: Saxon-EE 9.4.0.6
>>>
>>>
>>> Regards
>>>
>>> Bjvrn D|nckel.

We've tried this out on oXygen 14.2 and we're unable to reproduce the
problem.

We can try it again perhaps with a specific stylesheet, source document, and
schema.

Michael Kay
Saxonica


On 10 Apr 2013, at 09:15, bjoern.duenckel@xxxxxxxxxxxxxxxxxxx wrote:

>> I'm always a bit reticent about discussing product-specific issues on =
>> this list - I like to be helpful to users and I don't mind doing it in =
>> public, but I'm conscious that not everyone on the list is interested. =
>> There's a Saxon specific forum athttp://saxonica.plan.io  which you are =
>> welcome to use.
> Thanks for the advice!
> I will use the forum for Saxon realted issues in the future.
>
>> I can't see any obvious reason for this behaviour. Schema validation per =
>> se shouldn't lose the comments, although it ignores them. How are you =
>> invoking the transformation?
> I used an oXygen transformation scenario to invoke the transformation:
>
>   oXygen XML Editor 14.2, build 2013030817
>   Transformer: Saxon-EE 9.4.0.6
>
>
> Regards
>
> Bjvrn D|nckel.

I'm always a bit reticent about discussing product-specific issues on =
this list - I like to be helpful to users and I don't mind doing it in =
public, but I'm conscious that not everyone on the list is interested. =
There's a Saxon specific forum athttp://saxonica.plan.io  which you are =
welcome to use.

Thanks for the advice!
I will use the forum for Saxon realted issues in the future.

I can't see any obvious reason for this behaviour. Schema validation per =
se shouldn't lose the comments, although it ignores them. How are you =
invoking the transformation?

   oXygen XML Editor 14.2, build 2013030817
   Transformer: Saxon-EE 9.4.0.6

I'm always a bit reticent about discussing product-specific issues on this
list - I like to be helpful to users and I don't mind doing it in public, but
I'm conscious that not everyone on the list is interested. There's a Saxon
specific forum at http://saxonica.plan.io which you are welcome to use.

I can't see any obvious reason for this behaviour. Schema validation per se
shouldn't lose the comments, although it ignores them. How are you invoking
the transformation?

Michael Kay
Saxonica

On 9 Apr 2013, at 16:44, bjoern.duenckel@xxxxxxxxxxxxxxxxxxx wrote:

> With Saxon-EE 9.4.0.6 I can't adress comment nodes.
>
>   Source
>   -----------------------------------------------
>   <?xml version="1.0" encoding="UTF-8"?>
>   <r>
>        <!-- This is a comment. -->
>   </r>
>   -----------------------------------------------
>
>   Stylesheet
>   -----------------------------------------------
>   <?xml version="1.0" encoding="UTF-8"?>
>   <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>   version="2.0">
>        <xsl:output method="text"/>
>        <xsl:template match="/">
>            <xsl:value-of select="count(//comment())"/>
>        </xsl:template>
>   </xsl:stylesheet>
>   -----------------------------------------------
>
>   Output with Saxon-EE 9.4.0.6
>   -----------------------------------------------
>   0
>   -----------------------------------------------
>
>   Output with Saxon-PE 9.4.0.6 (and any other Transformer I tried)
>   -----------------------------------------------
>   1
>   -----------------------------------------------
>
>
> Do you agree, that this is a saxon bug?
> Or am I missing something about schema-awareness that would explain this
behavior?
>
> Regards
>
> Bjvrn D|nckel

   Source
   -----------------------------------------------
   <?xml version="1.0" encoding="UTF-8"?>
   <r>
        <!-- This is a comment. -->
   </r>
   -----------------------------------------------

   Stylesheet
   -----------------------------------------------
   <?xml version="1.0" encoding="UTF-8"?>
   <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   version="2.0">
        <xsl:output method="text"/>
        <xsl:template match="/">
            <xsl:value-of select="count(//comment())"/>
        </xsl:template>
   </xsl:stylesheet>
   -----------------------------------------------

   Output with Saxon-EE 9.4.0.6
   -----------------------------------------------
   0
   -----------------------------------------------

   Output with Saxon-PE 9.4.0.6 (and any other Transformer I tried)
   -----------------------------------------------
   1
   -----------------------------------------------

I asked because  I know more from getting an answer than I would have
if I hadn't asked or if I had just experimented.

It looks like I had multiple submissions..... sorry about that ....
problems with gmail formatting.

On Tue, Apr 9, 2013 at 2:22 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
> You're asking as if we had a choice. But the semantics have been well
defined since 1999, so why raise the question now?
>
> And the approach you are proposing is very paternalistic. Disallowing things
because the user might not understand what they are doing is not generally a
good design principle, especially when it breaks orthogonality. (Treating the
separate parts of a union pattern differently was already a serious breach of
orthogonality, but that's a different question.)
>
> Michael Kay
> Saxonica
>
> On 9 Apr 2013, at 12:37, Ihe Onwuka wrote:
>
>> Given that the sub parts of a unionized pattern retain their individual
>> priorities
>>
>> <xsl:template match="A|B[*] ......
>>
>> What should be the semantic if you were to now specify a priority
attribute.
>> The instinctive reaction would be they should all get the same priority
but
>> there not a case for saying that it should not be allowed.
>>
>> The rationale would be to highlight that the subparts may have had
>> different priorities in the first place so making their priorities
>> homogenous might actually be the source of what would be a hard to find
bug.

You're asking as if we had a choice. But the semantics have been well defined
since 1999, so why raise the question now?

And the approach you are proposing is very paternalistic. Disallowing things
because the user might not understand what they are doing is not generally a
good design principle, especially when it breaks orthogonality. (Treating the
separate parts of a union pattern differently was already a serious breach of
orthogonality, but that's a different question.)

Michael Kay
Saxonica

On 9 Apr 2013, at 12:37, Ihe Onwuka wrote:

> Given that the sub parts of a unionized pattern retain their individual
> priorities
>
> <xsl:template match="A|B[*] ......
>
> What should be the semantic if you were to now specify a priority
attribute.
> The instinctive reaction would be they should all get the same priority but
> there not a case for saying that it should not be allowed.
>
> The rationale would be to highlight that the subparts may have had
> different priorities in the first place so making their priorities
> homogenous might actually be the source of what would be a hard to find
bug.

It may have made for  better conversation  to translate an/your
implementation of the Y-combinator into the target language and
highlight where and if it breaks down.

On Sat, Oct 13, 2012 at 8:03 PM, Costello, Roger L. <costello@xxxxxxxxx> wrote:
> Hi Folks,
>
> Is it possible to do recursion in an anonymous function?

Given that the sub parts of a unionized pattern retain their individual
priorities

<xsl:template match="A|B[*] ......

What should be the semantic if you were to now specify a priority attribute.
The instinctive reaction would be they should all get the same priority but
 there not a case for saying that it should not be allowed.

The rationale would be to highlight that the subparts may have had
different priorities in the first place so making their priorities
homogenous might actually be the source of what would be a hard to find bug.

David,

Can you give a more complex example, how "variable in structure" those
citations may be. This may also shed some light on the kind of processing you
want to do. Changing tags to characters (why are you using ASCII instead of
some high Unicode character from the private use area?) and then back to tags
seems not a very interesting thing

- Michael

Am 08.04.2013 um 20:15 schrieb David Sewell <dsewell@xxxxxxxxxxxx>:

> I expect this has been discussed here before, but I can't locate any
relevant
> discussion, so here goes.
>
> We have input data with many unmarked short-title citations that look like
this:
>
>   Sprague, <hi rend="italic">Braintree Families</hi>
>
> We want to wrap them inside another element, in our case a <ref> to the
> bibliographic expansion. We have a venerable chain of XSLT 2.0 transforms
that
> does this, and pretty well, by preprocessing the data to convert all those
<hi>
> tags into a pair of unique ASCII characters, so that we can do
string-matching
> operations within a single text node that now includes something like
>
>   Sprague, "Braintree Families%
>
> which is easy to handle with xsl:analyze-string. then once we've wrapped all
the
> strings we need to, we post-process with xsl:analyze-string to put the <hi>
> elements back in.
>
> In practice, given the proper regexes, this works quite well and provides
the
> desired output, but I always feel a bit guilty about the hackishness of the
> approach. Given that the citations are quite variable in structure (usually
but
> not always containing <hi> elements, with various combinations of text nodes
at
> start and end), I've never come up with a good general-purpose way to
operate
> purely on elements and text nodes without the convert-tags-to-characters
step.
> Is there one (or more)?
>
> David S.

Something new in addition to the treatment of this subject in the
current thread -- tail-call optimization and how to survive its
complete lack in current XPath 3.0 processors:

http://dnovatchev.wordpress.com/2013/04/08/recursion-with-anonymous-inline-functions-in-xpath-3-0-part-ii/




On Sun, Oct 14, 2012 at 9:44 AM, Costello, Roger L. <costello@xxxxxxxxx> wrote:
>
> Thank you very much Dimitre. That is a fantastic technique.
>
> Using Dimitre's technique, I implemented the "until" function:
>
> <?xml version="1.0" encoding="UTF-8"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                             xmlns:xs="http://www.w3.org/2001/XMLSchema"
>                             version="3.0">
>
>     <xsl:output method="text"/>
>
>     <xsl:variable name="isNegative" select="function($x as xs:integer) {$x lt 0}" />
>     <xsl:variable name="decrement" select="function($x as xs:integer) {$x - 1}" />
>     <xsl:variable name="_until" select="
>                   function(
>                                     $p as function(item()*) as xs:boolean,
>                                     $f as function(item()*) as item()*,
>                                     $x as item()*,
>                                     $_until as function(function(), function(), item()*, function()) as item()*
>                                  ) as item()*
>                      {if ($p($x)) then $x else $_until($p, $f, $f($x), $_until)}
>         " />
>
>     <xsl:variable name="until" select="
>                   function(
>                                      $p as function(item()*) as xs:boolean,
>                                      $f as function(item()*) as item()*,
>                                      $x as item()*
>                                   ) as item()*
>                       {$_until($p, $f, $x, $_until)}
>           " />
>
>     <xsl:template match="/">
>         <xsl:value-of select="$until($isNegative, $decrement, 3)" />
>     </xsl:template>
>
> </xsl:stylesheet>
>
> /Roger
>



--
Cheers,
Dimitre Novatchev
---------------------------------------
Truly great madness cannot be achieved without significant intelligence.
---------------------------------------
To invent, you need a good imagination and a pile of junk
-------------------------------------
Never fight an inanimate object
-------------------------------------
To avoid situations in which you might make mistakes may be the
biggest mistake of all
------------------------------------
Quality means doing it right when no one is looking.
-------------------------------------
You've achieved success in your field when you don't know whether what
you're doing is work or play
-------------------------------------
Facts do not cease to exist because they are ignored.
-------------------------------------
Typing monkeys will write all Shakespeare's works in 200yrs.Will they
write all patents, too? :)
-------------------------------------
I finally figured out the only reason to be alive is to enjoy it.

I expect this has been discussed here before, but I can't locate any relevant
discussion, so here goes.

We have input data with many unmarked short-title citations that look like this:

Sprague, <hi rend="italic">Braintree Families</hi>

We want to wrap them inside another element, in our case a <ref> to the
bibliographic expansion. We have a venerable chain of XSLT 2.0 transforms that
does this, and pretty well, by preprocessing the data to convert all those <hi>
tags into a pair of unique ASCII characters, so that we can do string-matching
operations within a single text node that now includes something like

Sprague, "Braintree Families%

which is easy to handle with xsl:analyze-string. then once we've wrapped all the
strings we need to, we post-process with xsl:analyze-string to put the <hi>
elements back in.

In practice, given the proper regexes, this works quite well and provides the
desired output, but I always feel a bit guilty about the hackishness of the
approach. Given that the citations are quite variable in structure (usually but
not always containing <hi> elements, with various combinations of text nodes at
start and end), I've never come up with a good general-purpose way to operate
purely on elements and text nodes without the convert-tags-to-characters step.
Is there one (or more)?

David S.

Anaylze-string can match the string, and wrap the <ref> around the matching
substring easily.
The problem is that the matching-substring/context-item has it's markup
stripped out, so what you
would get is:

<note>See for example <ref target="st002">Jay, Unpublished Papers</ref>,
4:123.</note>

instead of:

<note>See for example <ref target="st002">Jay, <i>Unpublished
Papers</i></ref>, 4:123.</note>


And I can't think of any way to preserve the markup except by escaping it in
some manner.

-- Steve Majewski / UVA Alderman Library



On Apr 8, 2013, at 4:26 PM, David Sewell wrote:

> A sample of the citation abbreviations that need to be matched (for
simplicity, <i> is used to indicate italics), from the lookup table used by
the transforms (omitting the expansions of the abbreviations that are in the
lookup table also):
>
> <abbr xml:id="st001"><i>Cal. Franklin Papers</i>, A.P.S.</abbr>
> <abbr xml:id="st002">Jay, <i>Unpublished Papers</i></abbr>
> <abbr xml:id="st003"><i>JCC</i></abbr>
> <abbr xml:id="st004"><i>Oxford Classical Dicy.</i></abbr>
> <abbr xml:id="st005">U.S. Census, 1790</abbr>
>
> In the incoming XML, abbreviations like those above appear in running text
without wrapper elements. The automated process to add wrappers needs to
operate on string values that often cross <i> boundaries., as in the first two
examples. So one might find in running text:
>
>    <note>See for example Jay, <i>Unpublished Papers</i>, 4:123.</note>
>
> which needs to be transformed into
>
>    <note>See for example <ref target="st002">Jay, <i>Unpublished
Papers</i></ref>, 4:123.</note>
>
> The XPath //note[matches(., 'Jay, Unpublished Papers')] will match the
input <note>, but the complexity is writing a template that wraps the
appropriate portions of the note in a <ref> element. That's why our
preprocessing converts <i> tags in both input and lookup table to single text
characters to make the string matching relatively simple.
>
> And we do in fact use unusual Unicode for markers in our current transform,
the example I gave substituted markers that would show up in everyone's
email.
>
> David
>
> On Apr 8, 2013, at 2:58 PM, Michael M|ller-Hillebrand <mmh@xxxxxxxxx>
wrote:
>
>> David,
>>
>> Can you give a more complex example, how "variable in structure" those
citations may be. This may also shed some light on the kind of processing you
want to do. Changing tags to characters (why are you using ASCII instead of
some high Unicode character from the private use area?) and then back to tags
seems not a very interesting thing
>>
>> - Michael
>>
>> Am 08.04.2013 um 20:15 schrieb David Sewell <dsewell@xxxxxxxxxxxx>:
>>
>>> I expect this has been discussed here before, but I can't locate any
relevant
>>> discussion, so here goes.
>>>
>>> We have input data with many unmarked short-title citations that look like
this:
>>>
>>> Sprague, <hi rend="italic">Braintree Families</hi>
>>>
>>> We want to wrap them inside another element, in our case a <ref> to the
>>> bibliographic expansion. We have a venerable chain of XSLT 2.0 transforms
that
>>> does this, and pretty well, by preprocessing the data to convert all those
<hi>
>>> tags into a pair of unique ASCII characters, so that we can do
string-matching
>>> operations within a single text node that now includes something like
>>>
>>> Sprague, "Braintree Families%
>>>
>>> which is easy to handle with xsl:analyze-string. then once we've wrapped
all the
>>> strings we need to, we post-process with xsl:analyze-string to put the
<hi>
>>> elements back in.
>>>
>>> In practice, given the proper regexes, this works quite well and provides
the
>>> desired output, but I always feel a bit guilty about the hackishness of
the
>>> approach. Given that the citations are quite variable in structure
(usually but
>>> not always containing <hi> elements, with various combinations of text
nodes at
>>> start and end), I've never come up with a good general-purpose way to
operate
>>> purely on elements and text nodes without the convert-tags-to-characters
step.
>>> Is there one (or more)?
>>>
>>> David S.

A sample of the citation abbreviations that need to be matched (for
simplicity, <i> is used to indicate italics), from the lookup table used by
the transforms (omitting the expansions of the abbreviations that are in the
lookup table also):

<abbr xml:id="st001"><i>Cal. Franklin Papers</i>, A.P.S.</abbr>
<abbr xml:id="st002">Jay, <i>Unpublished Papers</i></abbr>
<abbr xml:id="st003"><i>JCC</i></abbr>
<abbr xml:id="st004"><i>Oxford Classical Dicy.</i></abbr>
<abbr xml:id="st005">U.S. Census, 1790</abbr>

In the incoming XML, abbreviations like those above appear in running text
without wrapper elements. The automated process to add wrappers needs to
operate on string values that often cross <i> boundaries., as in the first two
examples. So one might find in running text:

    <note>See for example Jay, <i>Unpublished Papers</i>, 4:123.</note>

which needs to be transformed into

    <note>See for example <ref target="st002">Jay, <i>Unpublished
Papers</i></ref>, 4:123.</note>

The XPath //note[matches(., 'Jay, Unpublished Papers')] will match the  input
<note>, but the complexity is writing a template that wraps the appropriate
portions of the note in a <ref> element. That's why our preprocessing converts
<i> tags in both input and lookup table to single text characters to make the
string matching relatively simple.

And we do in fact use unusual Unicode for markers in our current transform,
the example I gave substituted markers that would show up in everyone's
email.

David

On Apr 8, 2013, at 2:58 PM, Michael M|ller-Hillebrand <mmh@xxxxxxxxx> wrote:

> David,
>
> Can you give a more complex example, how "variable in structure" those
citations may be. This may also shed some light on the kind of processing you
want to do. Changing tags to characters (why are you using ASCII instead of
some high Unicode character from the private use area?) and then back to tags
seems not a very interesting thing
>
> - Michael
>
> Am 08.04.2013 um 20:15 schrieb David Sewell <dsewell@xxxxxxxxxxxx>:
>
>> I expect this has been discussed here before, but I can't locate any
relevant
>> discussion, so here goes.
>>
>> We have input data with many unmarked short-title citations that look like
this:
>>
>>  Sprague, <hi rend="italic">Braintree Families</hi>
>>
>> We want to wrap them inside another element, in our case a <ref> to the
>> bibliographic expansion. We have a venerable chain of XSLT 2.0 transforms
that
>> does this, and pretty well, by preprocessing the data to convert all those
<hi>
>> tags into a pair of unique ASCII characters, so that we can do
string-matching
>> operations within a single text node that now includes something like
>>
>>  Sprague, "Braintree Families%
>>
>> which is easy to handle with xsl:analyze-string. then once we've wrapped
all the
>> strings we need to, we post-process with xsl:analyze-string to put the <hi>
>> elements back in.
>>
>> In practice, given the proper regexes, this works quite well and provides
the
>> desired output, but I always feel a bit guilty about the hackishness of the
>> approach. Given that the citations are quite variable in structure (usually
but
>> not always containing <hi> elements, with various combinations of text
nodes at
>> start and end), I've never come up with a good general-purpose way to
operate
>> purely on elements and text nodes without the convert-tags-to-characters
step.
>> Is there one (or more)?
>>
>> David S.

I expect this has been discussed here before, but I can't locate any relevant
discussion, so here goes.

We have input data with many unmarked short-title citations that look like
this:

   Sprague, <hi rend="italic">Braintree Families</hi>

We want to wrap them inside another element, in our case a <ref> to the
bibliographic expansion. We have a venerable chain of XSLT 2.0 transforms that
does this, and pretty well, by preprocessing the data to convert all those
<hi>
tags into a pair of unique ASCII characters, so that we can do string-matching
operations within a single text node that now includes something like

   Sprague, "Braintree Families%

which is easy to handle with xsl:analyze-string. then once we've wrapped all
the
strings we need to, we post-process with xsl:analyze-string to put the <hi>
elements back in.

In practice, given the proper regexes, this works quite well and provides the
desired output, but I always feel a bit guilty about the hackishness of the
approach. Given that the citations are quite variable in structure (usually
but
not always containing <hi> elements, with various combinations of text nodes
at
start and end), I've never come up with a good general-purpose way to operate
purely on elements and text nodes without the convert-tags-to-characters step.
Is there one (or more)?

David S.

--
David Sewell, Editorial and Technical Manager
ROTUNDA, The University of Virginia Press
PO Box 400314, Charlottesville, VA 22904-4314 USA
Email: dsewell@xxxxxxxxxxxx   Tel: +1 434 924 9973
Web: http://rotunda.upress.virginia.edu/

Thanks, I can see that argument. but now you open a can of worms for me. So say your template for b just writes output to the standard result tree (not separate files). Why doesn't the same argument for parallelism apply there?

Probably answering my own question here, I'm guessing the difference is writing to a file more or less serially vs writing to a tree. The processor can write to multiple locations in the tree and keep track of where multiple b outputs should be created, but not as well supported writing to a file from multiple sources (unless your willing to live with jumbled results in the file).

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

Is good publicity for you now. Can you repurpose one
of your humanities ones?

Papers are due 22 April (the 19th extended)

This is your wakeup call.


--Debbie

Dan,

In your own answer to your own question you also have another solution
to your problem: generate your results in a temporary tree, then
serialize that, taking care when you do so not to serialize the same
results more than once.

This is essentially Ken's solution (offered early in the thread)
except it determines whether results are being duplicated after
generating them (but before serializing them), not before. This may
make it a bit more robust in the face of complexity -- and it also
exposes the extra work you are asking the processor to do, which Ken's
heuristic approach avoids. (So I'd probably prefer Ken's way at least
until things got really complicated.)

Cheers, Wendell

On Thu, Apr 4, 2013 at 11:22 PM, Dan Vint <dvint@xxxxxxxxx> wrote:
> Thanks, I can see that argument. but now you open a can of worms for me. So
> say your template for b just writes output to the standard result tree (not
> separate files). Why doesn't the same argument for parallelism apply there?
>
> Probably answering my own question here, I'm guessing the difference is
> writing to a file more or less serially vs writing to a tree. The processor
> can write to multiple locations in the tree and keep track of where multiple
> b outputs should be created, but not as well supported writing to a file
> from multiple sources (unless your willing to live with jumbled results in
> the file).
>
> Thanks again.
>
> ..dan
>
>
> At 07:56 PM 4/4/2013, you wrote:
>>
>> At 2013-04-04 19:37 -0700, Dan Vint wrote:
>>>
>>> I can live with the rule, just would like to understand the logic.
>>
>>
>> Consider the following scenario.  An XML document has two elements <b>:
>>
>>   <a>
>>     <b id="1">...</b>
>>     <b id="2">...</b>
>>   </a>
>>
>> An XSLT stylesheet uses the built-in template rule for <a> and has a
>> template rule for <b>:
>>
>>    <xsl:template match="b">
>>      <xsl:result-document href="output.xml">
>>        <xsl:copy-of select="."/>
>>      </xsl:result-document>
>>    </xsl:template>
>>
>> If the specification allowed this, then without considering the
>> opportunities of parallelism, one might come to the conclusion that the file
>> "output.xml" would always contain:
>>
>>     <b id="1">...</b><b id="2">...</b>
>>
>> The problem is that the specification does not require the XSLT processor
>> to complete the processing of the first <b> before starting or even ending
>> the processing of the second <b>.  Sure a single-process implementation "X"
>> likely would.  But a parallelized (is that a word?) implementation "Y"
>> running on multiple CPUs could very well fully process the second <b> before
>> the first <b> if it chose to do so.  Its only obligation is to arrange the
>> resulting tree with the result of processing the first <b> before the result
>> of processing the second <b>.  This obligation ensures that the result of
>> processing by "X" is identical to the result of processing by "Y".  But
>> there is no obligation on what the processor does to get to that result.
>>
>> When using <xsl:result-document> the processor is not building the result
>> tree.  It is creating a completely separate result.  If the instruction
>> required "re-opening" of the file for append, processor "X" likely would
>> produce the expected result, but processor "Y" in the situation above would
>> produce an unexpected result.  Two processors would produce two results.
>>
>> And this is also why one cannot assert that the writing to the file is
>> even finished before the next attempt to write to the file starts.  The file
>> handle could very well still be left open by one parallel process when the
>> other is ready to open it for itself.  So it can't be used even if the file
>> is opened for write and not for append.
>>
>> Note that some of my students have come to class thinking that you have to
>> fully complete an <xsl:result-document> before starting another one to
>> another URI, but I tell them that is not the case.  You can nest
>> <xsl:result-document> instructions to different URI target locations, and
>> the nested <xsl:result-document> will complete the nested file and resume
>> the "outer" file output when done, without having to close and re-open the
>> outer file.  This has been a very handy feature when fragmenting files.  And
>> this would be another reason not to allow the same URI to be used.
>>
>>> I know the what now, even though I don't understand why the rule exists
>>> ;-)
>>
>>
>> I hope the explanation above has helped.
>>
>> . . . . . . . . . Ken
>>
>> --
>> Contact us for world-wide XML consulting and instructor-led training |
>> Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
>> Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
>> G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
>> Google+ profile: https://plus.google.com/116832879756988317389/about |
>> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |
>>
>
> ---------------------------------------------------------------------------
> Danny Vint
>
> Panoramic Photography
> http://www.dvint.com
>
> voice: 619-938-3610
>



-- 
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^

> The problem is that the specification does not require the XSLT processor to
complete the processing of the first <b> before starting or even ending the
processing of the second <b>.  Sure a single-process implementation "X" likely
would.  But a parallelized (is that a word?) implementation "Y" running on
multiple CPUs could very well fully process the second <b> before the first
<b> if it chose to do so.  Its only obligation is to arrange the resulting
tree with the result of processing the first <b> before the result of
processing the second <b>.  This obligation ensures that the result of
processing by "X" is identical to the result of processing by "Y".  But there
is no obligation on what the processor does to get to that result.
>
> When using <xsl:result-document> the processor is not building the result
tree.  It is creating a completely separate result.  If the instruction
required "re-opening" of the file for append, processor "X" likely would
produce the expected result, but processor "Y" in the situation above would
produce an unexpected result.  Two processors would produce two results.
>
> And this is also why one cannot assert that the writing to the file is even
finished before the next attempt to write to the file starts.  The file handle
could very well still be left open by one parallel process when the other is
ready to open it for itself.  So it can't be used even if the file is opened
for write and not for append.
>
Indeed. Saxon-EE 9.5 will execute xsl:result-document instructions
asynchronously, so the rule in the spec that you can't write two documents to
the same URI turns out to be very useful. If you do something like this:

<xsl:for-each select="employee">
 <xsl:result-document href="{@ssn}">
   <xsl:copy-of select="."/>
 </xsl:result-document>
</xsl:for-each>

then you might well have a dozen threads operating at once, each copying a
different employee element to a different result file. If the URIs were not
unique, this would cause havoc - in fact the optimization would not really be
possible.

I can see why you find the rule irritating - I've been in the same situation
myself - but it's there for a very good reason.

And by the way, your mental model that the result file is closed when the
xsl:result-document end tag is encountered might be a convenient way of
thinking about things, and perhaps not even too far from reality, but it's not
the way the semantics of the language work, and sooner or later it will lead
to difficulties in understanding what's going on. It's a bit like imagining
that when you do readFile('xyz') in Java, the file is closed when the closing
')' is encountered.

Michael Kay
Saxonica

I can live with the rule, just would like to understand the logic.

  <a>
    <b id="1">...</b>
    <b id="2">...</b>
  </a>

   <xsl:template match="b">
     <xsl:result-document href="output.xml">
       <xsl:copy-of select="."/>
     </xsl:result-document>
   </xsl:template>

I know the what now, even though I don't understand why the rule exists ;-)

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

On 4 Apr 2013, at 21:42, dvint@xxxxxxxxx wrote:

> I understand why this might be an issue to have two different streams
> writing to the same file, but should this always fail just because the
> file is opened twice for write in one stylesheet?

It's not clear what you would like to happen. Do you want to see both outputs
appended to the same file? Even though it wouldn't be well-formed XML? Even
though the order of the results is unpredictable?

Or would you like one of the outputs to overwrite the other?

In fact, it's not too hard to workaround this problem. Add some kind of random
suffix to the URL generated in the result-document href attribute, and write
an OutputURIResolver that causes this suffix to be ignored.

Michael Kay
Saxonica

>
> I'm trying to process some DITA content that is using conrefs (think
> xinclude statements). So I have one file that makes 2 references to
> another file to include content from that second file.
>
> We want to change this arrangement such that there is only one includable
> section in a given file. So I'm splitting the second file into 2 new files
> and modifying the references accordingly in the first.
>
> Here is s simplified view of what is going on (for those that know DITA
> please excuse the pseudo code):
>
> Topic file structure:
>
> <concept>
>   <h1 conref="file2.xml#sysoutput"></h1>
>   <h2 conref=file2.xml#inline"></h2>
> </concept>
>
>
> File2.xml structure:
>
> <concept>
>    <h1 id="sysoutput">
>       <p>This is the first set of content</p>
>    </h1>
>    <h2 id="inline">
>       <p>this is the second referenced content</p>
>    </h2>
> </concept>
>
> Need to change this to be:
>
>
> Topic file structure:
>
> <concept>
>   <h1 conref="file2-sysoutput.xml#sysoutput"></h1>
>   <h2 conref=file2-inline.xml#inline"></h2>
> </concept>
>
>
> File2-sysoutput.xml structure:
>
> <concept>
>    <h1 id="sysoutput">
>       <p>This is the first set of content</p>
>    </h1>
> </concept>
>
>
> File2-inline.xml structure:
>
> <concept>
>    <h2 id="inline">
>       <p>this is the second referenced content</p>
>    </h2>
> </concept>
>
>
> So my stylesheet is processing the topic file. I have a template that is
> triggered when an @conref attribute is found and it creates the new
> attribute value as well as making the new file.
>
> <xsl:template name="make-conref">
> <xsl:param name="file" as="xs:string"/>
> <xsl:param name="conref-sourcefile" as="xs:string"/>
>  <xsl:result-document method="xml"  encoding="UTF-8" href="{$file}">
>     <concept>
> 	<xsl:apply-templates select="doc($conref-sourcefile)//*[@id=$target-id]"/>
>     </concept>
>  </xsl:result-document>
>
> <!-- return the new conref statement to replace the one we found -->
>   <xsl:attribute name="conref" select="$newconref"/>
> </xsl:template>
>
> So this template gets the modified filename that uses the id value to make
> it unique, processes the included section and closes the result document
> before continuing to the next content.
>
> I could see this error being raised if one of the conref'd sections
> actually made a circular reference to itself, but I have not been able to
> find this situation.
>
> One other detail is I'm using Kernow to process a directory with the same
> stylesheet. So maybe there is something with the caching going on? I've
> set the multi-threading to use a single thread so there should be no
> collisions there.
>
> Kernow reports that it is net.sf.saxon.trans.XPathException throwing the
> error.
>
> ..dan

On Thu, 2013-04-04 at 16:46 -0700, Dan Vint wrote:
> I guess what I'm expecting is that the result document is closed once 
> the </xslt:result-document> end tag is found.

This is a procedural do-this-then-that way of looking at XSLT.

However, XSLT stylesheets can be evaluated in any order, as long as the
end result meets the spec. XSLT is not a first-this-then-that language.

In addition, the XSLT stylesheet is read into memory and parsed long
before it's executed, so finding an end tag just marks the boundary of a
node in a tree.

Hope this helps.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

I guess what I'm expecting is that the result document is closed once the </xslt:result-document> end tag is found.

Instead XSLT seems to keep this memory around that it is there.

I'm happy with just over writing the last file created as it is all the same content each time.

Yeah maybe inefficient, but I expected it to work. Out of 3000 files I have to process with lots of need for this file splitting I found 2 that complain about writing to the same result document.

  http://www.w3.org/TR/2007/REC-xslt20-20070123/#element-result-document
  [ERR XTDE1490] It is a non-recoverable dynamic error for
  a transformation to generate two or more final result
  trees with the same URI.

With the first posting I wasn't sure where in the processing this was occurring, then I found the files that actually were trying to create the file twice. I still don't understand why this is a problem when the output file should be closed by the time the next write sequence is started.

   <xsl:if test="not(preceding::*[@conref=current()/@conref])">
     <xsl:result-document href=.......

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

Dear list,

I'm pleased to a new and very simple desktop tool.

XMLSpectrum-FX is a cross-platform open-source product, it generates
syntax-highlighted and formatted HTML from source code files or
snippets of XPath, XSLT (including 3.0), XProc, XML Schema and other
XML standards (currently working on XQuery support).

This tool is effectively a graphical front-end for the (GitHub hosted)
XMLSpectrum project which comprises a small set of XSLT files. The
front-end provides control for all the transform settings whilst the
XSLT is responsible for the parsing and rendering of the code. The
result of the transfrom is rendered in the embedded Webkit-based
browser.

For input, files can be drag and dropped onto the tool, URLs entered,
or code snippets copied and pasted into a text area.

(Note: Saxon-HE from Saxonica is used for all XSLT processing and is
distributed as part of the download.)

XMLSpectrum pays particular attention to the preservation of
whitespace and syntax-coloring of XPath. It is also capable of
correcting XML indentation that has gone wrong without corrupting the
relative indentation within the XML content (attributes or otherwise).

To help keep this product light, some of the more powerful XMLSpecturm
features such as XSLT package support are not included just yet.

Parts of this product have a dependency on Java 1.7.0_07 (due to the
use of Java-FX 2.0).

More details and the product download are available from the product site at:

http://qutoric.com/xmlspectrum/

Many thanks

Phil Fearon

At 2013-04-04 19:37 -0700, Dan Vint wrote:

I can live with the rule, just would like to understand the logic.

Consider the following scenario. An XML document has two elements <b>:

  <a>
    <b id="1">...</b>
    <b id="2">...</b>
  </a>

An XSLT stylesheet uses the built-in template rule for <a> and has a template rule for <b>:

   <xsl:template match="b">
     <xsl:result-document href="output.xml">
       <xsl:copy-of select="."/>
     </xsl:result-document>
   </xsl:template>

If the specification allowed this, then without considering the opportunities of parallelism, one might come to the conclusion that the file "output.xml" would always contain:

<b id="1">...</b><b id="2">...</b>

The problem is that the specification does not require the XSLT processor to complete the processing of the first <b> before starting or even ending the processing of the second <b>. Sure a single-process implementation "X" likely would. But a parallelized (is that a word?) implementation "Y" running on multiple CPUs could very well fully process the second <b> before the first <b> if it chose to do so. Its only obligation is to arrange the resulting tree with the result of processing the first <b> before the result of processing the second <b>. This obligation ensures that the result of processing by "X" is identical to the result of processing by "Y". But there is no obligation on what the processor does to get to that result.

When using <xsl:result-document> the processor is not building the result tree. It is creating a completely separate result. If the instruction required "re-opening" of the file for append, processor "X" likely would produce the expected result, but processor "Y" in the situation above would produce an unexpected result. Two processors would produce two results.

And this is also why one cannot assert that the writing to the file is even finished before the next attempt to write to the file starts. The file handle could very well still be left open by one parallel process when the other is ready to open it for itself. So it can't be used even if the file is opened for write and not for append.

Note that some of my students have come to class thinking that you have to fully complete an <xsl:result-document> before starting another one to another URI, but I tell them that is not the case. You can nest <xsl:result-document> instructions to different URI target locations, and the nested <xsl:result-document> will complete the nested file and resume the "outer" file output when done, without having to close and re-open the outer file. This has been a very handy feature when fragmenting files. And this would be another reason not to allow the same URI to be used.

I know the what now, even though I don't understand why the rule exists ;-)

I hope the explanation above has helped.

. . . . . . . . . Ken

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

---------------------------------------------------------------------------
Danny Vint

Panoramic Photography
http://www.dvint.com

It isn't a problem with the implementation, it is a formal aspect of the specification as cited above.

Could you simply check back to make sure you haven't already created the file?

   <xsl:if test="not(preceding::*[@conref=current()/@conref])">
     <xsl:result-document href=.......

So, for every unique conref attribute you'll get only a single invocation of <xsl:result-document>.

I hope this helps.

..dan
---------------------------------------------------------------------------
Danny Vint

Panoramic Photography
http://www.dvint.com

On Thu, 2013-04-04 at 16:46 -0700, Dan Vint wrote:
> I guess what I'm expecting is that the result document is closed once
> the </xslt:result-document> end tag is found.

This is a procedural do-this-then-that way of looking at XSLT.

However, XSLT stylesheets can be evaluated in any order, as long as the
end result meets the spec. XSLT is not a first-this-then-that language.

In addition, the XSLT stylesheet is read into memory and parsed long
before it's executed, so finding an end tag just marks the boundary of a
node in a tree.

Hope this helps.

Liam

--
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

---------------------------------------------------------------------------
Danny Vint

Panoramic Photography
http://www.dvint.com

The situation is that you are calling xsl:apply-imports when there is no
matching user-defined template rule in an imported stylesheet.

The XSLT 2.0 specification is clear about what happens here:

"If no matching template rule is found that satisfies these criteria, the
built-in template rule for the node kind is used."

The XSLT 1.0 specification is less clear on the subject. It says

(a) "xsl:apply-imports processes the current node using only template rules
that were imported into the stylesheet element containing the current template
rule", and

(b) "The built-in template rules are treated as if they were imported
implicitly before the stylesheet"

My belief is that if you read these two statements together, they indicate
that the same behaviour as in 2.0 is intended. There's room for debate,
however, because of the phrase "before the stylesheet" as distinct from "into
the stylesheet".

Michael Kay
Saxonica

On 4 Apr 2013, at 17:10, Bob Stayton wrote:

>
> According to Saxon author Michael Kay's website, his description of
> xsl:apply-imports is:
>
> "The effect is to search for a template that matches the current node and
> that is defined in a stylesheet that was imported (directly or indirectly,
> possibly via xsl:include) from the stylesheet containing the current
> template, and whose mode matches the current mode. If there is such a
> template, it is activated using the current node. If not, the call on
> xsl:apply-imports has no effect."
>
Yes. That was written a long time ago, and it's wrong. I will fix it.

OK, I know I "cried wolf" earlier. This time I mean it: the due-date for
submissions to Balisage and the pre-conference Symposium on Native XML
User Interfaces is almost here.

Papers are due on April 19th. That's soon!

Balisage Call for Participation:
http://www.balisage.net/Call4Participation.html
Native XML User Interfaces:
http://www.balisage.net/XML-Interfaces/index.html


Information about Balisage in general: http://www.balisage.net/ or
  info@xxxxxxxxxxxx


======================================================================
Balisage: The Markup Conference 2013          mailto:info@xxxxxxxxxxxx
August 6-9, 2013                              http://www.balisage.net
Preconference Symposium                       August 5, 2012
======================================================================

On 4 Apr 2013, at 21:42, dvint@xxxxxxxxx wrote:

> I understand why this might be an issue to have two different streams
> writing to the same file, but should this always fail just because the
> file is opened twice for write in one stylesheet?

It's not clear what you would like to happen. Do you want to see both outputs appended to the same file? Even though it wouldn't be well-formed XML? Even though the order of the results is unpredictable?

Or would you like one of the outputs to overwrite the other?

In fact, it's not too hard to workaround this problem. Add some kind of random suffix to the URL generated in the result-document href attribute, and write an OutputURIResolver that causes this suffix to be ignored.

Michael Kay
Saxonica

>
> I'm trying to process some DITA content that is using conrefs (think
> xinclude statements). So I have one file that makes 2 references to
> another file to include content from that second file.
>
> We want to change this arrangement such that there is only one includable
> section in a given file. So I'm splitting the second file into 2 new files
> and modifying the references accordingly in the first.
>
> Here is s simplified view of what is going on (for those that know DITA
> please excuse the pseudo code):
>
> Topic file structure:
>
> <concept>
> <h1 conref="file2.xml#sysoutput"></h1>
> <h2 conref=file2.xml#inline"></h2>
> </concept>
>
>
> File2.xml structure:
>
> <concept>
> <h1 id="sysoutput">
> <p>This is the first set of content</p>
> </h1>
> <h2 id="inline">
> <p>this is the second referenced content</p>
> </h2>
> </concept>
>
> Need to change this to be:
>
>
> Topic file structure:
>
> <concept>
> <h1 conref="file2-sysoutput.xml#sysoutput"></h1>
> <h2 conref=file2-inline.xml#inline"></h2>
> </concept>
>
>
> File2-sysoutput.xml structure:
>
> <concept>
> <h1 id="sysoutput">
> <p>This is the first set of content</p>
> </h1>
> </concept>
>
>
> File2-inline.xml structure:
>
> <concept>
> <h2 id="inline">
> <p>this is the second referenced content</p>
> </h2>
> </concept>
>
>
> So my stylesheet is processing the topic file. I have a template that is
> triggered when an @conref attribute is found and it creates the new
> attribute value as well as making the new file.
>
> <xsl:template name="make-conref">
> <xsl:param name="file" as="xs:string"/>
> <xsl:param name="conref-sourcefile" as="xs:string"/>
> <xsl:result-document method="xml" encoding="UTF-8" href="{$file}">
> <concept>
> <xsl:apply-templates select="doc($conref-sourcefile)//*[@id=$target-id]"/>
> </concept>
> </xsl:result-document>
>
> <!-- return the new conref statement to replace the one we found -->
> <xsl:attribute name="conref" select="$newconref"/>
> </xsl:template>
>
> So this template gets the modified filename that uses the id value to make
> it unique, processes the included section and closes the result document
> before continuing to the next content.
>
> I could see this error being raised if one of the conref'd sections
> actually made a circular reference to itself, but I have not been able to
> find this situation.
>
> One other detail is I'm using Kernow to process a directory with the same
> stylesheet. So maybe there is something with the caching going on? I've
> set the multi-threading to use a single thread so there should be no
> collisions there.
>
> Kernow reports that it is net.sf.saxon.trans.XPathException throwing the
> error.
>
> ..dan

---------------------------------------------------------------------------
Danny Vint

Panoramic Photography
http://www.dvint.com

It seems likely () (for grouping) was intended rather than [] (for a
character class)?

On 04/04/2013 08:04 AM, David Carlisle wrote:

On 04/04/2013 13:00, David Carlisle wrote:

On 04/04/2013 12:40, davep wrote:

<xsl:template
match="p[matches(normalize-space(), '^[the quick] |
[brown fox]' )]"

that matches either

a string that starts with one of the letters t h e ' ' q u i c k
followed by a space.

or string that contains
a space followed by one of the letters  b r o w n f x

the second clause should be

 or string that contains
 a space followed by one of the letters  b r o w n ' ' f x

Although you can't actually match a space followed by another space in
this context as you have used normalize-space on the input.

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs.
________________________________________________________________________

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Tks for the quick reply.

On 04/04/13 12:49, Martin Honnen wrote:

davep wrote:

If so, what patter matches a p element which starts with
the string "the quick brown" or contains "brown fox" please?

   <xsl:template match="p[matches(., '(^the quick brown)|brown
fox')]">...</xsl:template>

Are the brackets necessary Martin?

It looks like this is more the issue:

<concept>
   <h1 conref="file2.xml#sysoutput"></h1>
   <h1 conref=file2.xml#sysoutput"></h1>
</concept>

Same situation applies, tha the result document should be closed, but it
is writing to the same file twice within the session. This happens in
single file mode in kernow as well as the directory mode.


> I understand why this might be an issue to have two different streams
> writing to the same file, but should this always fail just because the
> file is opened twice for write in one stylesheet?
>
> I'm trying to process some DITA content that is using conrefs (think
> xinclude statements). So I have one file that makes 2 references to
> another file to include content from that second file.
>
> We want to change this arrangement such that there is only one includable
> section in a given file. So I'm splitting the second file into 2 new files
> and modifying the references accordingly in the first.
>
> Here is s simplified view of what is going on (for those that know DITA
> please excuse the pseudo code):
>
> Topic file structure:
>
> <concept>
>    <h1 conref="file2.xml#sysoutput"></h1>
>    <h2 conref=file2.xml#inline"></h2>
> </concept>
>
>
> File2.xml structure:
>
> <concept>
>     <h1 id="sysoutput">
>        <p>This is the first set of content</p>
>     </h1>
>     <h2 id="inline">
>        <p>this is the second referenced content</p>
>     </h2>
> </concept>
>
> Need to change this to be:
>
>
> Topic file structure:
>
> <concept>
>    <h1 conref="file2-sysoutput.xml#sysoutput"></h1>
>    <h2 conref=file2-inline.xml#inline"></h2>
> </concept>
>
>
> File2-sysoutput.xml structure:
>
> <concept>
>     <h1 id="sysoutput">
>        <p>This is the first set of content</p>
>     </h1>
> </concept>
>
>
> File2-inline.xml structure:
>
> <concept>
>     <h2 id="inline">
>        <p>this is the second referenced content</p>
>     </h2>
> </concept>
>
>
> So my stylesheet is processing the topic file. I have a template that is
> triggered when an @conref attribute is found and it creates the new
> attribute value as well as making the new file.
>
> <xsl:template name="make-conref">
> <xsl:param name="file" as="xs:string"/>
> <xsl:param name="conref-sourcefile" as="xs:string"/>
>   <xsl:result-document method="xml"  encoding="UTF-8" href="{$file}">
>      <concept>
> 	<xsl:apply-templates
> select="doc($conref-sourcefile)//*[@id=$target-id]"/>
>      </concept>
>   </xsl:result-document>
>
> <!-- return the new conref statement to replace the one we found -->
>    <xsl:attribute name="conref" select="$newconref"/>
> </xsl:template>
>
> So this template gets the modified filename that uses the id value to make
> it unique, processes the included section and closes the result document
> before continuing to the next content.
>
> I could see this error being raised if one of the conref'd sections
> actually made a circular reference to itself, but I have not been able to
> find this situation.
>
> One other detail is I'm using Kernow to process a directory with the same
> stylesheet. So maybe there is something with the caching going on? I've
> set the multi-threading to use a single thread so there should be no
> collisions there.
>
> Kernow reports that it is net.sf.saxon.trans.XPathException throwing the
> error.
>
> ..dan

If so, what patter matches a p element which starts with
the string "the quick brown" or contains "brown fox" please?

I understand why this might be an issue to have two different streams
writing to the same file, but should this always fail just because the
file is opened twice for write in one stylesheet?

I'm trying to process some DITA content that is using conrefs (think
xinclude statements). So I have one file that makes 2 references to
another file to include content from that second file.

We want to change this arrangement such that there is only one includable
section in a given file. So I'm splitting the second file into 2 new files
and modifying the references accordingly in the first.

Here is s simplified view of what is going on (for those that know DITA
please excuse the pseudo code):

Topic file structure:

<concept>
   <h1 conref="file2.xml#sysoutput"></h1>
   <h2 conref=file2.xml#inline"></h2>
</concept>


File2.xml structure:

<concept>
    <h1 id="sysoutput">
       <p>This is the first set of content</p>
    </h1>
    <h2 id="inline">
       <p>this is the second referenced content</p>
    </h2>
</concept>

Need to change this to be:


Topic file structure:

<concept>
   <h1 conref="file2-sysoutput.xml#sysoutput"></h1>
   <h2 conref=file2-inline.xml#inline"></h2>
</concept>


File2-sysoutput.xml structure:

<concept>
    <h1 id="sysoutput">
       <p>This is the first set of content</p>
    </h1>
</concept>


File2-inline.xml structure:

<concept>
    <h2 id="inline">
       <p>this is the second referenced content</p>
    </h2>
</concept>


So my stylesheet is processing the topic file. I have a template that is
triggered when an @conref attribute is found and it creates the new
attribute value as well as making the new file.

<xsl:template name="make-conref">
<xsl:param name="file" as="xs:string"/>
<xsl:param name="conref-sourcefile" as="xs:string"/>
  <xsl:result-document method="xml"  encoding="UTF-8" href="{$file}">
     <concept>
	<xsl:apply-templates select="doc($conref-sourcefile)//*[@id=$target-id]"/>
     </concept>
  </xsl:result-document>

<!-- return the new conref statement to replace the one we found -->
   <xsl:attribute name="conref" select="$newconref"/>
</xsl:template>

So this template gets the modified filename that uses the id value to make
it unique, processes the included section and closes the result document
before continuing to the next content.

I could see this error being raised if one of the conref'd sections
actually made a circular reference to itself, but I have not been able to
find this situation.

One other detail is I'm using Kernow to process a directory with the same
stylesheet. So maybe there is something with the caching going on? I've
set the multi-threading to use a single thread so there should be no
collisions there.

Kernow reports that it is net.sf.saxon.trans.XPathException throwing the
error.

..dan

I have uncovered a significant difference in the way xsltproc and Saxon (both 6 and 9)
handle xsl:apply-imports when using a template mode. It seem that Saxon
is doing the wrong thing here, but I wanted to ask if others interpret it
this way. I cannot find anything in the archive on this subject.

I'm processing this simple document book.xml:
...
with this stylesheet (modetest.xsl):
...
And the imported no-mode.xsl stylesheet is:
...
When I apply modetest.xsl to book.xml using xsltproc, the message output is
just:

Reached apply-imports in modetest.xsl

When I apply modetest.xsl to book.xml using Saxon, the output is:

Reached apply-imports in modetest.xsl
reached fallback in modetest.xsl for element title
reached fallback in modetest.xsl for element para

According to Saxon author Michael Kay's website, his description of
xsl:apply-imports is:

"The effect is to search for a template that matches the current node and
that is defined in a stylesheet that was imported (directly or indirectly,
possibly via xsl:include) from the stylesheet containing the current
template, and whose mode matches the current mode. If there is such a
template, it is activated using the current node. If not, the call on
xsl:apply-imports has no effect."

There is no template matching on book in mode="inside_mode" in the imported
stylesheet, so the call on xsl:apply-imports should have no effect.

Why is Saxon applying
templates in mode="inside_mode" to the children of book?

   http://www.w3.org/TR/1999/REC-xslt-19991116#apply-imports
   ...
   xsl:apply-imports processes the current node using only
   template rules that were imported into the stylesheet
   element containing the current template rule; the node is
   processed in the current template rule's mode.

   xsl:apply-imports reapplies the last-matched node in the
   last-matched mode using only the imported stylesheets
   (and it can't be used inside of a for-each).

  http://www.w3.org/TR/1999/REC-xslt-19991116#built-in-rule
  There is a built-in template rule to allow recursive processing
  to continue in the absence of a successful pattern match by an
  explicit template rule in the stylesheet.
  ...
  There is also a built-in template rule for each mode, which
  allows recursive processing to continue in the same mode in the
  absence of a successful pattern match by an explicit template
  rule in the stylesheet.

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

On 04/04/2013 12:40, davep wrote:

     <xsl:template
match="p[matches(normalize-space(), '^[the quick] |
[brown fox]' )]"

that matches either

a string that starts with one of the letters t h e ' ' q u i c k
followed by a space.

or string that contains
a space followed by one of the letters  b r o w n f x

 or string that contains
 a space followed by one of the letters  b r o w n ' ' f x

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

     <xsl:template
match="p[matches(normalize-space(), '^[the quick] |
[brown fox]' )]"

or string that contains
a space followed by one of the letters  b r o w n f x

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

davep wrote:

If so, what patter matches a p element which starts with
the string "the quick brown" or contains "brown fox" please?

   <xsl:template match="p[matches(., '(^the quick brown)|brown
fox')]">...</xsl:template>

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

	<xsl:template
match="p[matches(normalize-space(), '^[the quick] |
[brown fox]' )]"

I'm having problems interpreting this.
  I think
<p>   the quick .....</p> matches
<p>the quick... </p> matches

what role does the  | take please?
  a simple alternate?

http://www.w3.org/TR/xmlschema-2/#regexs
seems to show this

If so, what patter matches a p element which starts with
the string "the quick brown" or contains "brown fox" please?

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

I'm processing this simple document book.xml:
----------------------------------------------------------------------------------------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<book>
 <title>My book title</title>
 <para>My first para</para>
</book>
----------------------------------------------------------------------------------------------------------------------------

with this stylesheet (modetest.xsl):
----------------------------------------------------------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 version="1.0">

<xsl:template match="book">
 <xsl:apply-templates select="." mode="inside_mode"/>
</xsl:template>

<xsl:template match="book" mode="inside_mode">
 <xsl:choose>
   <xsl:when test="$myflag != 0">
     <xsl:message>Reached apply-imports in modetest.xsl</xsl:message>
     <xsl:apply-imports/>
   </xsl:when>
   <xsl:otherwise>
     <xsl:message>Reached otherwise in modetest.xsl</xsl:message>
   </xsl:otherwise>
 </xsl:choose>
</xsl:template>

<xsl:template match="*" mode="inside_mode">
 <xsl:message>reached fallback in modetest.xsl for element
    <xsl:value-of select="local-name()"/></xsl:message>
</xsl:template>

</xsl:stylesheet>
----------------------------------------------------------------------------------------------------------------------------

And the imported no-mode.xsl stylesheet is:
----------------------------------------------------------------------------------------------------------------------------
<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet
 xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
 version="1.0">

<xsl:template match="book">
 <xsl:choose>
   <xsl:when test="$myflag != 0">
     <xsl:message>Reached when in no_mode.xsl</xsl:message>
     <xsl:apply-imports/>
   </xsl:when>
   <xsl:otherwise>
     <xsl:message>Reached otherwise in no_mode.xsl</xsl:message>
   </xsl:otherwise>
 </xsl:choose>
</xsl:template>

</xsl:stylesheet>
----------------------------------------------------------------------------------------------------------------------------

When I apply modetest.xsl to book.xml using xsltproc, the message output is
just:

Reached apply-imports in modetest.xsl
reached fallback in modetest.xsl for element title
reached fallback in modetest.xsl for element para

According to Saxon author Michael Kay's website, his description of
xsl:apply-imports is:

"The effect is to search for a template that matches the current node and
that is defined in a stylesheet that was imported (directly or indirectly,
possibly via xsl:include) from the stylesheet containing the current
template, and whose mode matches the current mode. If there is such a
template, it is activated using the current node. If not, the call on
xsl:apply-imports has no effect."

There is no template matching on book in mode="inside_mode" in the imported
stylesheet, so the call on xsl:apply-imports should have no effect.  That is
what I see when I process with xsltproc.  However, Saxon continues
processing the children of book in that mode, even though there is no
xsl:apply-templates to trigger such processing.   Why is Saxon applying
templates in mode="inside_mode" to the children of book?

Bob Stayton
Sagehill Enterprises
bobs@xxxxxxxxxxxx

On 04/04/2013 13:00, David Carlisle wrote:

On 04/04/2013 12:40, davep wrote:

<xsl:template
match="p[matches(normalize-space(), '^[the quick] |
[brown fox]' )]"

that matches either

a string that starts with one of the letters t h e ' ' q u i c k
followed by a space.

or string that contains
a space followed by one of the letters  b r o w n f x

the second clause should be

 or string that contains
 a space followed by one of the letters  b r o w n ' ' f x

Although you can't actually match a space followed by another space in this context as you have used normalize-space on the input.

David

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses by Star. The service is
powered by MessageLabs. ________________________________________________________________________

--
Michael Sokolov
Senior Architect
Safari Books Online

Using XSLT 2, this combination:

 <xsl:strip-space elements = "*" />
 <xsl:template match="element()|attribute()">... skip selected *|@* ... />
 <xsl:template match="text()|@_ix">
   <xsl:copy-of select="."/>
 </xsl:template>
 <xsl:template match="comment()">
   <xsl:copy-of select="."/><xsl:text>
</xsl:text>
 </xsl:template>

is the best I could do to preserve the original comment and element
layout, shown with beginning of input and output XML, below. Can this
be improved? Losing empty lines is tolerable, losing line breaks is
not so great.

Thanks
Wolfgang

Beginning of input XML:
=============================================
<ns2:cca_rom_db xmlns:ns2="/rss/at/obb/cca" version="0.1">


<!-- changing: processor_data (0) -->
<!-- .    OREST Problem -->
<!-- .    check this hex values !!!!!!!!!!!!!!!! -->
<processor_data _ix="0" reo_bos_zentrale="----" />


<!-- __________CCA-patches IRT_______________ -->
<!-- changing: versions -->
<!-- .    not provided by OREST - done to minimize differences -->


<!-- changing: pcx_info -->
<!-- .    OREST - station time missing -->
<pcx_info _ix="1" ... />
===========================================

Head of output XML:
============================================
<ns2:cca_rom_db xmlns:ns2="/rss/at/obb/cca"><!-- changing:
processor_data (0) -->
<!-- .    OREST Problem -->
<!-- .    check this hex values !!!!!!!!!!!!!!!! -->
<processor_data _ix="0" reo_bos_zentrale="----"/>
   <!-- __________CCA-patches IRT_______________ -->
<!-- changing: versions -->
<!-- .    not provided by OREST - done to minimize differences -->
<!-- changing: pcx_info -->
<!-- .    OREST - station time missing -->
<pcx_info _ix="1" ... />
===========================================

On Wed, April 3, 2013 2:08 pm, Wolfgang Laun wrote:
> Using XSLT 2, this combination:
>
>  <xsl:strip-space elements = "*" />

If you don't strip white-space and do use:

<xsl:output method="xml" indent="no" />

then you should get your existing white-space without the added indent:

> <processor_data _ix="0" reo_bos_zentrale="----"/>
>    <!-- __________CCA-patches IRT_______________ -->

Since you say you want to skip some elements, you may also want a template
to skip the white-space nodes before/after the skipped elements.

Regards,



Tony Graham                                   tgraham@xxxxxxxxxx
Consultant                                 http://www.mentea.net
Mentea       13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland
 --  --  --  --  --  --  --  --  --  --  --  --  --  --  --  --
    XML, XSL-FO and XSLT consulting, training and programming

Using XSLT 2, this combination:

  <xsl:strip-space elements = "*" />
  <xsl:template match="element()|attribute()">... skip selected *|@* ... />
  <xsl:template match="text()|@_ix">
    <xsl:copy-of select="."/>
  </xsl:template>
  <xsl:template match="comment()">
    <xsl:copy-of select="."/><xsl:text>
</xsl:text>
  </xsl:template>

is the best I could do to preserve the original comment and element
layout, shown with beginning of input and output XML, below. Can this
be improved? Losing empty lines is tolerable, losing line breaks is
not so great.

Thanks
Wolfgang

<xsl:template match="/comment()" priority="2">
   <xsl:copy-of select="."/><xsl:text>&#10;</xsl:text>
<xsl:text>

<xsl:template match="comment()">
   <xsl:copy-of select="."/>
<xsl:text>

<xsl:template match="/" priority="2">
  <xsl:text>&#10;</xsl:text>
  <xsl:apply-templates/>
<xsl:text>

________________________________________________________________________
The Numerical Algorithms Group Ltd is a company registered in England
and Wales with company number 1249803. The registered office is:
Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

>  <xsl:strip-space elements = "*" />

> is the best I could do to preserve the original comment and element
> layout, shown with beginning of input and output XML, below. Can this
> be improved? Losing empty lines is tolerable, losing line breaks is
> not so great.

Hi,

It's not clear what you are trying to do as your code conflicts with
your wordy description... maybe produce a simple small complete sample
with required output.

cheers
andrew


--
Andrew Welch
http://andrewjwelch.com

When I Have done collecting results and have had time to analyze it I will be
publishing the results,
but I dont want to rush it, I want to make sure the data is clean and analysis
is done well.
IMHO premature publication is worse than none.


----------------------------------------
David A. Lee
dlee@xxxxxxxxxxx
http://www.xmlsh.org

-----Original Message-----
From: davep [mailto:davep@xxxxxxxxxxxxx]
Sent: Thursday, March 28, 2013 3:25 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re:  XML Schema 1.0 files

Thanks Mike,
    Quite comprehensive.

On 27/03/13 22:54, Michael Kay wrote:
> In general, extracting information from schema documents using XSLT is
> difficult, unless you are prepared to make assumptions and
> approximations - for example, you might be prepared to ignore the impact
> of xs:redefine, or the risk of finding xs:element declarations within an
> xs:documentation element.
>
> In this case I think you can get a reasonable answer fairly easily. If
> you find an <xs:element name="N"> then the namespace in question is one
> of the following:
>
> (a) if parent::xs:schema then ../@targetNamespace if present, else ""
>
> (b) otherwise, if normalize-space(@form)="qualified" or empty(@form) and
> normalize-space(ancestor::xs:schema/@elementFormDefault)="qualified",
> then ancestor::xs:schema/@targetNamespace if present, else ""
>
> (c) otherwise, ""
>
> I think this caters for most possibilities; an exception is chameleon
> include where the declarations in a schema document acquire the target
> namespace of the including schema document.


I know the chameleon 'method' is used, but am prepared to accept
problems from that. Since I'm file based I have no option (other than
to assume the 'parent' including file targetNamespace.

Also that redefine isn't used.

Thanks.



regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

On Sat, Mar 30, 2013 at 8:03 PM, Dorothy Hoskins
<dorothy.hoskins@xxxxxxxxx> wrote:
>
> HI, I have an interesting problem in that I am trying to figure out
> how to load and process a CSS file to grab content from CSS class
> definitions and poke them into XML files.
(...)
> The commonalities of the CSS text are that a
> line which contains "{" has the information I want for the
> class/@element and class/@name.

CSS parsing is difficult; it's usually better to use an existing
library that deals with all the quirks that real-life css can have. In
Python, 'cssutils' is pretty good.

This Python code (10 lines) will do a basic xml encoding of css rules:

# start Python code
import cssutils, gnosis.xml.pickle

css = {}
sheet = cssutils.parseFile("yourcssfile.css")

for rule in sheet:
  if rule.type == rule.STYLE_RULE:
    css[rule.selectorText] = {}
    for property in rule.style:
      css[rule.selectorText][property.name] = property.value

print gnosis.xml.pickle.dumps(css)
# end Python code

When applied to this css:

pre {
    padding: 5px;
    background-color: #eeffcc;
    color: #333333;
    line-height: 120%;
    border: 1px solid #ac9;
    border-left: none;
    border-right: none;
}
tt {
    background-color: #ecf0f3;
    padding: 0 1px 0 1px;
    font-size: 0.95em;
}
th {
    background-color: #ede;
}
.warning tt {
    background: #efc2c2;
}
.note tt {
    background: #d6d6d6;
}
.viewcode-back {
    font-family: sans-serif;
}
div.viewcode-block:target {
    background-color: #f4debf;
    border-top: 1px solid #ac9;
    border-bottom: 1px solid #ac9;
}

It will produce this xml:

<?xml version="1.0"?>
<!DOCTYPE PyObject SYSTEM "PyObjects.dtd">
<PyObject family="obj" type="builtin_wrapper"  class="_EmptyClass">
<attr name="__toplevel__" type="dict" id="3068659748" >
  <entry>
    <key type="string">pre</key>
    <val type="dict" id="3068659068" >
      <entry>
        <key type="string">color</key>
        <val type="string">#333</val>
      </entry>
      <entry>
        <key type="string">border-right</key>
        <val type="string">none</val>
      </entry>
      <entry>
        <key type="string">padding</key>
        <val type="string">5px</val>
      </entry>
      <entry>
        <key type="string">border-left</key>
        <val type="string">none</val>
      </entry>
      <entry>
        <key type="string">border</key>
        <val type="string">1px solid #ac9</val>
      </entry>
      <entry>
        <key type="string">line-height</key>
        <val type="string">120%</val>
      </entry>
      <entry>
        <key type="string">background-color</key>
        <val type="string">#efc</val>
      </entry>
    </val>
  </entry>
  <entry>
    <key type="string">tt</key>
    <val type="dict" id="3068660428" >
      <entry>
        <key type="string">padding</key>
        <val type="string">0 1px 0 1px</val>
      </entry>
      <entry>
        <key type="string">font-size</key>
        <val type="string">0.95em</val>
      </entry>
      <entry>
        <key type="string">background-color</key>
        <val type="string">#ecf0f3</val>
      </entry>
    </val>
  </entry>
  <entry>
    <key type="string">div.viewcode-block:target</key>
    <val type="dict" id="3069557180" >
      <entry>
        <key type="string">border-top</key>
        <val type="string">1px solid #ac9</val>
      </entry>
      <entry>
        <key type="string">background-color</key>
        <val type="string">#f4debf</val>
      </entry>
      <entry>
        <key type="string">border-bottom</key>
        <val type="string">1px solid #ac9</val>
      </entry>
    </val>
  </entry>
  <entry>
    <key type="string">.warning tt</key>
    <val type="dict" id="3069532468" >
      <entry>
        <key type="string">background</key>
        <val type="string">#efc2c2</val>
      </entry>
    </val>
  </entry>
  <entry>
    <key type="string">th</key>
    <val type="dict" id="3069554868" >
      <entry>
        <key type="string">background-color</key>
        <val type="string">#ede</val>
      </entry>
    </val>
  </entry>
  <entry>
    <key type="string">.viewcode-back</key>
    <val type="dict" id="3068661516" >
      <entry>
        <key type="string">font-family</key>
        <val type="string">sans-serif</val>
      </entry>
    </val>
  </entry>
  <entry>
    <key type="string">.note tt</key>
    <val type="dict" id="3068658388" >
      <entry>
        <key type="string">background</key>
        <val type="string">#d6d6d6</val>
      </entry>
    </val>
  </entry>
</attr>
</PyObject>

- - -

It's a really simple start; some things that are easy to improve --
the resulting xml is not very pretty, but that can be improved with
either further XSLT processing ("entry" elements that have
"val[@type='dict']" children are CSSrules; "entry" elements that only
have string vals as children are properties) or a custom XML
serializer (Gnosis is a little antique anyway).

Also, we only retrieve rules and properties from the parsed css, but
there can be many other things (priority, imports, etc. etc.)

The main problem, regarding your requirements, is that css selectors
can be complex, and AFAIK cssutils doesn't parse selector expressions
(it does parse multiple selectors into list of selectors, but not
selector elements into element|class|name|child|descendant etc.)

Hope this helps.

Regards,
Emmanuel BC)guC)


PS: I'm not sure, but I think Saxon-CE directly exposes some css
properties; that may also help?

HI, I have an interesting problem in that I am trying to figure out
how to load and process a CSS file to grab content from CSS class
definitions and poke them into XML files.
In the source XML, which is scraped from XHTML pages, I find images
with CSS classes:
<img class="frame-3" src="image/file.jpeg" alt="image" />

In the CSS of the ePub, I find the dimension information that I want
for the image:
img.frame-3 {
     height:448px;
     width:339px;
}

My desired XML output is <image height="44" width="339"
src="image/file.jpeg" alt="image" />

I have the idea of grabbing the CSS and processing the CSS text to
achieve something like this:
<css>
<class element="img" name="frame-3">
<attribute name="height" value="44"/><!-- px assumed in XHTML -->
<attribute name="width" value="339"/>
</class>
</css>

I know I can handle everything else I want to do once I get the CSS
into an XML structure. The commonalities of the CSS text are that a
line which contains "{" has the information I want for the
class/@element and class/@name. The subsequent lines until the "}"
occurs have the content that I want to process into the attribute/name
and attribute/value. It seems like regex is the way to go but I don't
know how to start - do I load the CSS file into a variable as
xs:string? process it as unparsed-text? if anyone knows a good example
of creating such structure from a text input in the archives or
online, please point me in the right direction.
Thanks, Dorothy

--
Gerrit Imsieke
GeschC$ftsfC<hrer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit.imsieke@xxxxxxxxx, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

GeschC$ftsfC<hrer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard VC6ckler

HI, I have an interesting problem in that I am trying to figure out
how to load and process a CSS file to grab content from CSS class
definitions and poke them into XML files.
In the source XML, which is scraped from XHTML pages, I find images
with CSS classes:
<img class="frame-3" src="image/file.jpeg" alt="image" />

In the CSS of the ePub, I find the dimension information that I want
for the image:
img.frame-3 {
    height:448px;
    width:339px;
}

My desired XML output is <image height="44" width="339"
src="image/file.jpeg" alt="image" />

I have the idea of grabbing the CSS and processing the CSS text to
achieve something like this:
<css>
<class element="img" name="frame-3">
<attribute name="height" value="44"/><!-- px assumed in XHTML -->
<attribute name="width" value="339"/>
</class>
</css>

I know I can handle everything else I want to do once I get the CSS
into an XML structure. The commonalities of the CSS text are that a
line which contains "{" has the information I want for the
class/@element and class/@name. The subsequent lines until the "}"
occurs have the content that I want to process into the attribute/name
and attribute/value. It seems like regex is the way to go but I don't
know how to start - do I load the CSS file into a variable as
xs:string? process it as unparsed-text? if anyone knows a good example
of creating such structure from a text input in the archives or
online, please point me in the right direction.
Thanks, Dorothy

--
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

HI, I have an interesting problem in that I am trying to figure out
how to load and process a CSS file to grab content from CSS class
definitions and poke them into XML files.
In the source XML, which is scraped from XHTML pages, I find images
with CSS classes:
<img class="frame-3" src="image/file.jpeg" alt="image" />

In the CSS of the ePub, I find the dimension information that I want
for the image:
img.frame-3 {
    height:448px;
    width:339px;
}

My desired XML output is <image height="44" width="339"
src="image/file.jpeg" alt="image" />

I have the idea of grabbing the CSS and processing the CSS text to
achieve something like this:
<css>
<class element="img" name="frame-3">
<attribute name="height" value="44"/><!-- px assumed in XHTML -->
<attribute name="width" value="339"/>
</class>
</css>

I know I can handle everything else I want to do once I get the CSS
into an XML structure. The commonalities of the CSS text are that a
line which contains "{" has the information I want for the
class/@element and class/@name. The subsequent lines until the "}"
occurs have the content that I want to process into the attribute/name
and attribute/value. It seems like regex is the way to go but I don't
know how to start - do I load the CSS file into a variable as
xs:string? process it as unparsed-text? if anyone knows a good example
of creating such structure from a text input in the archives or
online, please point me in the right direction.
Thanks, Dorothy

The network is iphone4 over 100 mb/5mb fiber and wifi.



El 28/03/2013, a las 13:29, David Lee <dlee@xxxxxxxxxxx> escribiC3:

> I am conducting research on real-world JSON and XML browser performance.
> I would appreciate anyone with a few minutes to give it a try and send me
comments.   And if possible forward to your network.
> ( Note: This test is NOT intended to test everything  ... its a focused test
with a few controlled variables).
>
> What You Do
>
> Go to
>    http://speedtest.xmlsh.org
>
> Click "Run Tests And Submit..."
> Test takes about 1 - 3 minutes depending on your internet and device speed.
>
> Repeat as often as have patience on as many difference OS's, machines,
browser vendors and versions and devices.
> I am particularly interested in mobile devices as these have had much less
coverage in these kinds of experiments, but anything you can try is valuable.
>
> Please feel free to pass this link on ... I will be updating the tests
pending comments of this initial public beta and then intend on distributing
the test to a wider audience (including full source).
>
> The results are intended to be published publicly after enough data
collection and analysis has been completed.
>
> Your participation is hoped to bring world peace, let cats sleep with dogs,
stop a zombie Armageddon and let Henny Penny come to terms with her
hallucinations about the sky falling.
>
> Thank you for any assistance and comments.
>
> ----------------------------------------
> David A. Lee
> dlee@xxxxxxxxxxx
> http://www.xmlsh.org

Done!

Could you share the results?



El 28/03/2013, a las 13:29, David Lee <dlee@xxxxxxxxxxx> escribiC3:

> I am conducting research on real-world JSON and XML browser performance.
> I would appreciate anyone with a few minutes to give it a try and send me
comments.   And if possible forward to your network.
> ( Note: This test is NOT intended to test everything  ... its a focused test
with a few controlled variables).
>
> What You Do
>
> Go to
>    http://speedtest.xmlsh.org
>
> Click "Run Tests And Submit..."
> Test takes about 1 - 3 minutes depending on your internet and device speed.
>
> Repeat as often as have patience on as many difference OS's, machines,
browser vendors and versions and devices.
> I am particularly interested in mobile devices as these have had much less
coverage in these kinds of experiments, but anything you can try is valuable.
>
> Please feel free to pass this link on ... I will be updating the tests
pending comments of this initial public beta and then intend on distributing
the test to a wider audience (including full source).
>
> The results are intended to be published publicly after enough data
collection and analysis has been completed.
>
> Your participation is hoped to bring world peace, let cats sleep with dogs,
stop a zombie Armageddon and let Henny Penny come to terms with her
hallucinations about the sky falling.
>
> Thank you for any assistance and comments.
>
> ----------------------------------------
> David A. Lee
> dlee@xxxxxxxxxxx
> http://www.xmlsh.org

I am conducting research on real-world JSON and XML browser performance.
I would appreciate anyone with a few minutes to give it a try and send me
comments.   And if possible forward to your network.
( Note: This test is NOT intended to test everything  ... its a focused test
with a few controlled variables).

What You Do

Go to
   http://speedtest.xmlsh.org

Click "Run Tests And Submit..."
Test takes about 1 - 3 minutes depending on your internet and device speed.

Repeat as often as have patience on as many difference OS's, machines, browser
vendors and versions and devices.
I am particularly interested in mobile devices as these have had much less
coverage in these kinds of experiments, but anything you can try is valuable.

Please feel free to pass this link on ... I will be updating the tests pending
comments of this initial public beta and then intend on distributing the test
to a wider audience (including full source).

The results are intended to be published publicly after enough data collection
and analysis has been completed.

Your participation is hoped to bring world peace, let cats sleep with dogs,
 stop a zombie Armageddon and let Henny Penny come to terms with her
hallucinations about the sky falling.

Thank you for any assistance and comments.

----------------------------------------
David A. Lee
dlee@xxxxxxxxxxx
http://www.xmlsh.org

Thanks Mike,
   Quite comprehensive.

In general, extracting information from schema documents using XSLT is
difficult, unless you are prepared to make assumptions and
approximations - for example, you might be prepared to ignore the impact
of xs:redefine, or the risk of finding xs:element declarations within an
xs:documentation element.

In this case I think you can get a reasonable answer fairly easily. If
you find an <xs:element name="N"> then the namespace in question is one
of the following:

(a) if parent::xs:schema then ../@targetNamespace if present, else ""

(b) otherwise, if normalize-space(@form)="qualified" or empty(@form) and
normalize-space(ancestor::xs:schema/@elementFormDefault)="qualified",
then ancestor::xs:schema/@targetNamespace if present, else ""

(c) otherwise, ""

I think this caters for most possibilities; an exception is chameleon
include where the declarations in a schema document acquire the target
namespace of the including schema document.

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Michael Kay
Saxonica

Given an XML schema, I want to find files containing definitions & references of a particular element

Root is

<xsd:schema xmlns="http://www.x"
    targetNamespace="http://www.x"
  ...

Later I see

<xsd:element ref="X"/>

and

<xsd:element name="X">
but also
<xsd:element ref="dc:X"/>

I'm looking for some xslt 2.0 that will combine
them to search for element X definitions and references
and report their namespace.
I'm working on a directory, so I'll be using collection() but
for one file all I want to know is
if element X (ref or def) is in the file, and if so, what the appropriate namespace is.
So the stylesheet parameters are the localname and the
returned value either nothing (not found) or the namespace in which the
element is, indicating it was found?
AFAICT in the above example, the namespace is /xsd:schema/@targetNamespace

Has anyone done this before please?

TiA

regards

You could look into XQuery - a number of XQuery implementations that can
live in servlets can talk to relational databases. You can filter the
output using XSLT too.  But that's still an architectural change.

Hi Ken,

Thanks for your generous help. I will check it out and see if I can make it
work.

Rick

-----Original Message-----
From: G. Ken Holman [mailto:g.ken.holman@xxxxxxxxx] On Behalf Of G. Ken
Holman
Sent: Wednesday, March 27, 2013 3:11 PM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx; xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re:  Processing tab delimited text with XSLT

At 2013-03-27 15:06 -0400, Rick Quatro wrote:
>I would like to process some tab-delimited text and am not sure how to 
>do this with XSLT. I want to import some tab-delimited text and export 
>a comma-separated file with some of the data rearranged, etc. Is XSLT 
>suitable for a task like this? I have the 2nd edition of Michael Kay's 
>book so if there are any pointers there, I would appreciate it. Thank you
very much.

I have some XSLT 2.0 templates ready to go for TSV and CSV files here:

   http://www.CraneSoftwrights.com/resources/#csv

I hope this helps.

. . . . . . . . Ken


--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013 |
Contact us for world-wide XML consulting and instructor-led training | Free
5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

--~--

I would like to process some tab-delimited text and am not sure how to do
this with XSLT. I want to import some tab-delimited text and export a
comma-separated file with some of the data rearranged, etc. Is XSLT suitable
for a task like this? I have the 2nd edition of Michael Kay's book so if
there are any pointers there, I would appreciate it. Thank you very much.

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

I would like to process some tab-delimited text and am not sure how to do
this with XSLT. I want to import some tab-delimited text and export a
comma-separated file with some of the data rearranged, etc. Is XSLT suitable
for a task like this? I have the 2nd edition of Michael Kay's book so if
there are any pointers there, I would appreciate it. Thank you very much.

Rick Quatro

On 27/03/13 11:34, Wolfgang Laun wrote:

I think I did something similar only recently. My XML schema had
attributes marking the "interesting" xsd:element (and xsd:attribute)
definitions. Based on this I created a key with the names of the
marked elements.

<xsl:key name="kSkips"
          match="element()[@my:mark='1']"
          use="@name"/>

Key lookup uses name() to identify an "interesting" element in the XML.

-W

I'm querying a set of files (cmd line, via xmlsh) so I don't have
a list of names

Basically they are all interesting?

Thanks Wolfgang

DaveP

On 27/03/2013, davep <davep@xxxxxxxxxxxxx> wrote:

On 27/03/13 10:56, Philip Fearon wrote:

I haven't done this myself (and I may be missing something obvious),
but have you tried using the XPath 2.0 fn:resolve-QName() function
(http://www.w3.org/TR/xpath-functions/#func-resolve-QName) ?

The xs:QName result of this function can then be used as the argument
for fn:namespace-uri-from-QName() to return the namespace URI.

Phil Fearon

I think not Phil?
net.sf.saxon.s9api.SaxonApiException: Function resolve-QName() must have
2 arguments

I want to query with a localname only?
This because the element may be in any one of a number of namespaces?

Thanks for the suggestion though.

regards

On Wed, Mar 27, 2013 at 10:14 AM, davep <davep@xxxxxxxxxxxxx> wrote:

Given an XML schema, I want to find files containing definitions &
references  of a particular element

Root is

<xsd:schema xmlns="http://www.x"
          targetNamespace="http://www.x"
    ...

Later I see

<xsd:element ref="X"/>

and

<xsd:element name="X">
but also
<xsd:element ref="dc:X"/>

I'm looking for some xslt 2.0 that will combine
them to search for element X definitions and references
and report their namespace.
I'm working on a directory, so I'll be using collection() but
for one file all I want to know is
if element X (ref or def) is in the  file, and if so, what the
appropriate
namespace is.
So the stylesheet parameters are the localname and the
returned value either nothing (not found) or the namespace in which
the
element is, indicating it was found?
AFAICT in the above example, the namespace is
/xsd:schema/@targetNamespace

Has anyone done this before please?

TiA

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

I think I did something similar only recently. My XML schema had
attributes marking the "interesting" xsd:element (and xsd:attribute)
definitions. Based on this I created a key with the names of the
marked elements.

<xsl:key name="kSkips"
         match="element()[@my:mark='1']"
         use="@name"/>

Key lookup uses name() to identify an "interesting" element in the XML.

-W


On 27/03/2013, davep <davep@xxxxxxxxxxxxx> wrote:
> On 27/03/13 10:56, Philip Fearon wrote:
>> I haven't done this myself (and I may be missing something obvious),
>> but have you tried using the XPath 2.0 fn:resolve-QName() function
>> (http://www.w3.org/TR/xpath-functions/#func-resolve-QName) ?
>>
>> The xs:QName result of this function can then be used as the argument
>> for fn:namespace-uri-from-QName() to return the namespace URI.
>>
>> Phil Fearon
>
>
> I think not Phil?
> net.sf.saxon.s9api.SaxonApiException: Function resolve-QName() must have
> 2 arguments
>
> I want to query with a localname only?
> This because the element may be in any one of a number of namespaces?
>
> Thanks for the suggestion though.
>
> regards
>
>
>>
>> On Wed, Mar 27, 2013 at 10:14 AM, davep <davep@xxxxxxxxxxxxx> wrote:
>>> Given an XML schema, I want to find files containing definitions &
>>> references  of a particular element
>>>
>>> Root is
>>>
>>> <xsd:schema xmlns="http://www.x"
>>>          targetNamespace="http://www.x"
>>>    ...
>>>
>>> Later I see
>>>
>>> <xsd:element ref="X"/>
>>>
>>> and
>>>
>>> <xsd:element name="X">
>>> but also
>>> <xsd:element ref="dc:X"/>
>>>
>>>
>>> I'm looking for some xslt 2.0 that will combine
>>> them to search for element X definitions and references
>>> and report their namespace.
>>> I'm working on a directory, so I'll be using collection() but
>>> for one file all I want to know is
>>> if element X (ref or def) is in the  file, and if so, what the
>>> appropriate
>>> namespace is.
>>> So the stylesheet parameters are the localname and the
>>> returned value either nothing (not found) or the namespace in which the
>>> element is, indicating it was found?
>>> AFAICT in the above example, the namespace is
>>> /xsd:schema/@targetNamespace
>>>
>>> Has anyone done this before please?
>>>
>>> TiA
>>>
>>> regards
>>>
>>> --
>>> Dave Pawson
>>> XSLT XSL-FO FAQ.
>>> http://www.dpawson.co.uk
>>>
>>
>>
>
>
>
> regards
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk

The only way to get the data from one to the other without putting it all in
memory is to run them in separate threads with a shared buffer.

However... How large is your output? It's quite possible to handle 100Mb or so
before you have to resort to streaming. And surely 100Mb is far more than you
want to send to a browser. Perhaps you're dealing with much smaller data sizes
and you just need to change your system configuration so it doesn't run out of
memory?

Thanks for the advice,
--
John English

I think I did something similar only recently. My XML schema had
attributes marking the "interesting" xsd:element (and xsd:attribute)
definitions. Based on this I created a key with the names of the
marked elements.

<xsl:key name="kSkips"
          match="element()[@my:mark='1']"
          use="@name"/>

Key lookup uses name() to identify an "interesting" element in the XML.

-W

I'm querying a set of files (cmd line, via xmlsh) so I don't have
a list of names

On 27/03/2013, davep <davep@xxxxxxxxxxxxx> wrote:

On 27/03/13 10:56, Philip Fearon wrote:

I haven't done this myself (and I may be missing something obvious),
but have you tried using the XPath 2.0 fn:resolve-QName() function
(http://www.w3.org/TR/xpath-functions/#func-resolve-QName) ?

The xs:QName result of this function can then be used as the argument
for fn:namespace-uri-from-QName() to return the namespace URI.

Phil Fearon

I think not Phil?
net.sf.saxon.s9api.SaxonApiException: Function resolve-QName() must have
2 arguments

I want to query with a localname only?
This because the element may be in any one of a number of namespaces?

Thanks for the suggestion though.

regards

On Wed, Mar 27, 2013 at 10:14 AM, davep <davep@xxxxxxxxxxxxx> wrote:

Given an XML schema, I want to find files containing definitions &
references  of a particular element

Root is

<xsd:schema xmlns="http://www.x"
          targetNamespace="http://www.x"
    ...

Later I see

<xsd:element ref="X"/>

and

<xsd:element name="X">
but also
<xsd:element ref="dc:X"/>

I'm looking for some xslt 2.0 that will combine
them to search for element X definitions and references
and report their namespace.
I'm working on a directory, so I'll be using collection() but
for one file all I want to know is
if element X (ref or def) is in the  file, and if so, what the
appropriate
namespace is.
So the stylesheet parameters are the localname and the
returned value either nothing (not found) or the namespace in which the
element is, indicating it was found?
AFAICT in the above example, the namespace is
/xsd:schema/@targetNamespace

Has anyone done this before please?

TiA

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

On Wed, 2013-03-27 at 12:04 +0200, John English wrote:
> [...] I'm displaying tables out of a DB 
> with options to filter the selected rows and also select the number of rows per 
> page (10, 20, 50, 100, ALL). 

You could look into XQuery - a number of XQuery implementations that can
live in servlets can talk to relational databases. You can filter the
output using XSLT too.  But that's still an architectural change.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

I haven't done this myself (and I may be missing something obvious),
but have you tried using the XPath 2.0 fn:resolve-QName() function
(http://www.w3.org/TR/xpath-functions/#func-resolve-QName) ?

The xs:QName result of this function can then be used as the argument
for fn:namespace-uri-from-QName() to return the namespace URI.

Phil Fearon

I want to query with a localname only?
This because the element may be in any one of a number of namespaces?

On Wed, Mar 27, 2013 at 10:14 AM, davep <davep@xxxxxxxxxxxxx> wrote:

Given an XML schema, I want to find files containing definitions &
references  of a particular element

Root is

<xsd:schema xmlns="http://www.x"
         targetNamespace="http://www.x"
   ...

Later I see

<xsd:element ref="X"/>

and

<xsd:element name="X">
but also
<xsd:element ref="dc:X"/>

I'm looking for some xslt 2.0 that will combine
them to search for element X definitions and references
and report their namespace.
I'm working on a directory, so I'll be using collection() but
for one file all I want to know is
if element X (ref or def) is in the  file, and if so, what the appropriate
namespace is.
So the stylesheet parameters are the localname and the
returned value either nothing (not found) or the namespace in which the
element is, indicating it was found?
AFAICT in the above example, the namespace is /xsd:schema/@targetNamespace

Has anyone done this before please?

TiA

regards

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

I haven't done this myself (and I may be missing something obvious),
but have you tried using the XPath 2.0 fn:resolve-QName() function
(http://www.w3.org/TR/xpath-functions/#func-resolve-QName) ?

The xs:QName result of this function can then be used as the argument
for fn:namespace-uri-from-QName() to return the namespace URI.

Phil Fearon

On Wed, Mar 27, 2013 at 10:14 AM, davep <davep@xxxxxxxxxxxxx> wrote:
> Given an XML schema, I want to find files containing definitions &
> references  of a particular element
>
> Root is
>
> <xsd:schema xmlns="http://www.x"
>         targetNamespace="http://www.x"
>   ...
>
> Later I see
>
> <xsd:element ref="X"/>
>
> and
>
> <xsd:element name="X">
> but also
> <xsd:element ref="dc:X"/>
>
>
> I'm looking for some xslt 2.0 that will combine
> them to search for element X definitions and references
> and report their namespace.
> I'm working on a directory, so I'll be using collection() but
> for one file all I want to know is
> if element X (ref or def) is in the  file, and if so, what the appropriate
> namespace is.
> So the stylesheet parameters are the localname and the
> returned value either nothing (not found) or the namespace in which the
> element is, indicating it was found?
> AFAICT in the above example, the namespace is /xsd:schema/@targetNamespace
>
> Has anyone done this before please?
>
> TiA
>
> regards
>
> --
> Dave Pawson
> XSLT XSL-FO FAQ.
> http://www.dpawson.co.uk

<xsd:schema xmlns="http://www.x"
	targetNamespace="http://www.x"
  ...

<xsd:element name="X">
but also
<xsd:element ref="dc:X"/>

--
Dave Pawson
XSLT XSL-FO FAQ.
http://www.dpawson.co.uk

Michael Kay
Saxonica

Apologies in advance: this is not an XSLT-specific question, but I thought someone here might be able to help me anyway...

I have an XSLT filter which transforms XML output from a servlet to HTML. The filter uses a CharResponseWrapper to extract the response output as a string and then run it through the transformer:

      CharResponseWrapper wrapper =
          new CharResponseWrapper((HttpServletResponse)response);
      chain.doFilter(request,wrapper);
      s = wrapper.toString();
      if (s.length() > 0) {
        Transformer transformer = xslt.newTransformer();
        Source transformSource = new StreamSource(new StringReader(s));
        StreamResult result = new StreamResult(response.getWriter());
        transformer.transform(transformSource, result);
      }

This works fine unless the output is larger than a certain size, at which point I get an OutOfMemoryError.

The sensible way to deal with this would presumably be to connect up the response's output stream to the transformer's input source, so that I don't have to materialise all the output as a string before I start transforming it. I can't find any examples which show how I can do this; all the examples I've seen also work by materialising the output as a string before processing it.

It seems like I will need to move the transformation into the response wrapper, and maybe a separate thread to run the transformation while the response is being generated, but it all seems incredibly complicated. I'm hoping it's not as complicated as I imagine, and that someone here has already gone through all this and will be able to tell me how to proceed.

Please can anyone point me in the right direction here?

TIA,

      CharResponseWrapper wrapper =
          new CharResponseWrapper((HttpServletResponse)response);
      chain.doFilter(request,wrapper);
      s = wrapper.toString();
      if (s.length() > 0) {
        Transformer transformer = xslt.newTransformer();
        Source transformSource = new StreamSource(new StringReader(s));
        StreamResult result = new StreamResult(response.getWriter());
        transformer.transform(transformSource, result);
      }

TIA,
--
John English

We need more information, like what XSLT version/processor are you
using?  Are you trying to do this in browsers?  That sort of thing...

<advocacy>
My advice has more to do with your HTML, I'm a big fan of accessible
table markup styled with CSS, i.e. no @align, don't forget <tbody> and
<thead>, and don't be afraid to use <th> for table headings.  Just a
little effort in the XSLT and the resulting table, even if it's large,
is highly machine-readable, thus easily navigable by assistive devices.
I'm also a big fan of <caption> nested under <table>; this advice holds
for HTML 5.  XSLT makes it easy to generate beautiful, accessible
tables, so why not give it a try?
</advocacy>

-Eric

I have a structure like the one below:


        <ns1:Event>
            <ns1:Name>Anders Jacobsen - Anders Bardal</ns1:Name>
            <ns1:MatchId>331782</ns1:MatchId>
            <ns1:ArrangementId>100000214</ns1:ArrangementId>
            <ns1:ArrangementName>HS215</ns1:ArrangementName>
            <ns1:SportId>83</ns1:SportId>
            <ns1:SportName>Hopp</ns1:SportName>
            <ns1:Time>2013-03-22T15:15:00.000+01:00</ns1:Time>
            <ns1:Status Id="0">Ikke startet</ns1:Status>
            <ns1:Item id="13869">
                <ns1:Number>1</ns1:Number>
                <ns1:Name>Anders Jacobsen</ns1:Name>
                <ns1:ShortName>Jacobse</ns1:ShortName>
                <ns1:Abbreviation>Anders Jacobsen</ns1:Abbreviation>
            </ns1:Item>
            <ns1:Item id="13789">
                <ns1:Number>2</ns1:Number>
                <ns1:Name>Anders Bardal</ns1:Name>
                <ns1:ShortName>Bardal</ns1:ShortName>
                <ns1:Abbreviation>Anders Bardal</ns1:Abbreviation>
            </ns1:Item>
            <ns1:BetObject Name="H2H - duell" Id="181292">
                <ns1:BetObjectNumber>56</ns1:BetObjectNumber>
                <ns1:Date>2013-03-22T14:15:00.000+01:00</ns1:Date>
                <ns1:SaleStartTime>2013-03-21T11:15:00.000+01:00</ns1:SaleSta
rtTime>
                <ns1:SaleStopTime>2013-03-22T14:15:00.000+01:00</ns1:SaleStop
Time>
                <ns1:SaleStatusNo>1</ns1:SaleStatusNo>
                <ns1:SaleStatusName>Open</ns1:SaleStatusName>
                <ns1:SaleAmount>0</ns1:SaleAmount>
                <ns1:Selection>
                    <ns1:SelectionSeqNo>1</ns1:SelectionSeqNo>
                    <ns1:SelectionName>Anders Jacobsen</ns1:SelectionName>
                    <ns1:SelectionOdds>1.35</ns1:SelectionOdds>
                    <ns1:Withdrawn>false</ns1:Withdrawn>
                </ns1:Selection>
                <ns1:Selection>
                    <ns1:SelectionSeqNo>2</ns1:SelectionSeqNo>
                    <ns1:SelectionName>Anders Bardal</ns1:SelectionName>
                    <ns1:SelectionOdds>2.5</ns1:SelectionOdds>
                    <ns1:Withdrawn>false</ns1:Withdrawn>
                </ns1:Selection>
                <ns1:AllowedCombinations>
                    <ns1:Min>2</ns1:Min>
                    <ns1:Max>10</ns1:Max>
                </ns1:AllowedCombinations>
                <ns1:SaleChannels>
                    <ns1:SaleChannel>
                        <ns1:SaleChannelNo>1</ns1:SaleChannelNo>
                        <ns1:SaleStartTime>2013-03-22T00:00:00.000+01:00</ns1
:SaleStartTime>
                        <ns1:SaleStopTime>2013-03-22T14:15:00.000+01:00</ns1:
SaleStopTime>
                    </ns1:SaleChannel>
                    <ns1:SaleChannel>
                        <ns1:SaleChannelNo>2</ns1:SaleChannelNo>
                        <ns1:SaleStartTime>2013-03-21T11:15:00.000+01:00</ns1
:SaleStartTime>
                        <ns1:SaleStopTime>2013-03-22T14:15:00.000+01:00</ns1:
SaleStopTime>
                    </ns1:SaleChannel>
                    <ns1:SaleChannel>
                        <ns1:SaleChannelNo>7</ns1:SaleChannelNo>
                        <ns1:SaleStartTime>2013-03-21T11:15:00.000+01:00</ns1
:SaleStartTime>
                        <ns1:SaleStopTime>2013-03-22T14:15:00.000+01:00</ns1:
SaleStopTime>
                    </ns1:SaleChannel>
                </ns1:SaleChannels>
            </ns1:BetObject>
            <ns1:LivebetObjects>false</ns1:LivebetObjects>
            <ns1:BroadcastInformation>
                <ns1:ChannelName>Plancia - NRK</ns1:ChannelName>
            </ns1:BroadcastInformation>
            <ns1:ExternalEventId>0</ns1:ExternalEventId>
            <ns1:Withdrawn>false</ns1:Withdrawn>
        </ns1:Event>

That is supposed to be like this:
<table class="4-col">
        <tr>
          <td>16.55</td>
          <td>H</td>
          <td>U</td>
          <td>B</td>
        </tr>
      </table>
      <p class="txt" />
      <table class="9-col">
        <tr>
          <td>1</td>
          <td>Armenia - Tsjekkia</td>
          <td align="right">3,65</td>
          <td align="right">3,30</td>
          <td align="right">1,75</td>
          <td align="right">VMKB</td>
          <td align="center">H</td>
          <td align="center">U</td>
          <td align="center">B</td>
        </tr>
<tr>
          <td>2</td>
          <td>Armenia - Tsjekkia Handikap 1-0</td>
          <td align="right">1,75</td>
          <td align="right">3,45</td>
          <td align="right">3,15</td>
          <td align="right" />
          <td align="center">H</td>
          <td align="center">U</td>
          <td align="center">B</td>
        </tr>
      </table>
      <p class="txt" />
      <table class="4-col">
        <tr>
          <td>17.55</td>
....

So as you can see I need to group dates and times, and also sort the numbers.
I have tried the group-by and used substring-before(...,'T') but that has not
returned the wanted result.

I am currently playing with the idea of splitting the date into either two
elements or one element with two attributes. Then doing a second run on the
current with grouping and so on...
Is that the right path to follow, or do you a better idea on how to solve
this?



Best

Trond Husx
System Developer NTB, Norway

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

I've updated XMLSpectrum so it can now correct the formatting of
indented multi-line XPath expressions which may be corrupted by XSLT
editors when such expressions are copied and pasted or the host XSLT
is reformatted.

The highlight-file.xsl is the entry point in XMLSpectrum, so this can
be set up as a scenario within the editor with the XSLT parameters for
'indent' set to the required number of spaces and 'auto-trim' and
'css-inline' set to 'yes'. With my editor, the properly formatted code
is opened automatically in a browser from which I then paste into the
editor - unfortunately, I first need to disable the editor's own
'smart' formatting to prevent the formatting being corrupted again.

Using XMLSpectrum in this way is somewhat cumbersome, but seems to be
the best way of fixing this issue until XSLT editors improve support
for XPath formatting (at least one vendor is looking into this).

XMLSpectrum can be downloaded from Github on:

https://github.com/pgfearo/xmlspectrum

----------
Thanks

Phil Fearon

Reading the messages helps :-)
<xsl:variable name="doc" as="element()*" select="document($paths)/*"/>

Output OK. Thanks for improving my knowledge! (With a total of 200K
characters in the 3 files there certainly wasn't a noticeable
difference in execution speed.)

-W


On 23/03/2013, Wolfgang Laun <wolfgang.laun@xxxxxxxxx> wrote:
> Hi David,
>
> I tried this, and the proposed <xsl:variable name="doc"> produces an error.
>
> <xsl:variable name="paths" as="item()*">
>   <xsl:sequence select = "($p1,$p2,$p3)" />
> </xsl:variable>
> <xsl:variable name="doc" as="document-node()*"
> select="document($paths)/*"/>
>
> Warning: on line 34
>   Required item type of value of variable $doc is document-node();
> supplied value has item
>   type element(). The expression can succeed only if the supplied
> value is an empty sequence.
> Warning: on line 34 of strip4ilp.xsl:
>   The only value that can pass type-checking is an empty sequence.
> Required item type of
>   value of variable $doc is document-node(); supplied value has item
> type element()
> Warning: on line 34 of strip4ilp.xsl:
>   The only value that can pass type-checking is an empty sequence.
> Required item type of
>   value of variable $doc is document-node(); supplied value has item
> type element()
> Error on line 34 of strip4ilp.xsl:
>   XTTE0570: Required item type of value of variable $doc is
> document-node(); supplied value
>   has item type element({http://www.w3.org/2001/XMLSchema}schema,
> xs:anyType)
>
> -W
>
> On 23/03/2013, David Carlisle <davidc@xxxxxxxxx> wrote:
>> On 09/03/2013 16:02, Wolfgang Laun wrote:
>>> XSLT 2.0.
>>>
>>> I had to create a single document from several inputs (so that a key
>>> lookup could access them all with a single call):
>>>
>>> <xsl:variable name="doc" as="document-node()"> <xsl:document>
>>> <xsl:sequence select="document($paths)/*"/> </xsl:document>
>>> </xsl:variable> <xsl:key name="kSkips"
>>> match="element()[@omc:ilp='0']" use="@name"/>
>>>
>>> <xsl:variable name="look" select="key('kSkips',$name,$doc)"/>
>>>
>>
>> If you are only concatenating them for the key lookup that's an
>> expensive way to do it (unless your processor internally manages to
>> avoid copying all the nodes).
>>
>> Why not just look up along the sequence of documents?
>>
>> <xsl:variable name="docs" as="document-node()*"
>> select="document($paths)/*"/>
>>
>> <xsl:variable name="look" select="$docs/key('kSkips',$name,.)"/>
>>
>> David

Hi David,

I tried this, and the proposed <xsl:variable name="doc"> produces an error.

<xsl:variable name="paths" as="item()*">
  <xsl:sequence select = "($p1,$p2,$p3)" />
</xsl:variable>
<xsl:variable name="doc" as="document-node()*" select="document($paths)/*"/>

Warning: on line 34
  Required item type of value of variable $doc is document-node();
supplied value has item
  type element(). The expression can succeed only if the supplied
value is an empty sequence.
Warning: on line 34 of strip4ilp.xsl:
  The only value that can pass type-checking is an empty sequence.
Required item type of
  value of variable $doc is document-node(); supplied value has item
type element()
Warning: on line 34 of strip4ilp.xsl:
  The only value that can pass type-checking is an empty sequence.
Required item type of
  value of variable $doc is document-node(); supplied value has item
type element()
Error on line 34 of strip4ilp.xsl:
  XTTE0570: Required item type of value of variable $doc is
document-node(); supplied value
  has item type element({http://www.w3.org/2001/XMLSchema}schema, xs:anyType)

-W

On 23/03/2013, David Carlisle <davidc@xxxxxxxxx> wrote:
> On 09/03/2013 16:02, Wolfgang Laun wrote:
>> XSLT 2.0.
>>
>> I had to create a single document from several inputs (so that a key
>> lookup could access them all with a single call):
>>
>> <xsl:variable name="doc" as="document-node()"> <xsl:document>
>> <xsl:sequence select="document($paths)/*"/> </xsl:document>
>> </xsl:variable> <xsl:key name="kSkips"
>> match="element()[@omc:ilp='0']" use="@name"/>
>>
>> <xsl:variable name="look" select="key('kSkips',$name,$doc)"/>
>>
>
> If you are only concatenating them for the key lookup that's an
> expensive way to do it (unless your processor internally manages to
> avoid copying all the nodes).
>
> Why not just look up along the sequence of documents?
>
> <xsl:variable name="docs" as="document-node()*"
> select="document($paths)/*"/>
>
> <xsl:variable name="look" select="$docs/key('kSkips',$name,.)"/>
>
> David

Hi David,

I tried this, and the proposed <xsl:variable name="doc"> produces an
error.

<xsl:variable name="paths" as="item()*"> <xsl:sequence select =
"($p1,$p2,$p3)" /> </xsl:variable> <xsl:variable name="doc"
as="document-node()*" select="document($paths)/*"/>

Warning: on line 34 Required item type of value of variable $doc is
document-node(); supplied value has item type element().

Sorry I mis-read your code then copied it without seeing what it did,
you should do what I meant not what I wrote, lose the /* at the end.

XSLT 2.0.

I had to create a single document from several inputs (so that a key
lookup could access them all with a single call):

<xsl:variable name="doc" as="document-node()"> <xsl:document>
<xsl:sequence select="document($paths)/*"/> </xsl:document>
</xsl:variable> <xsl:key name="kSkips"
match="element()[@omc:ilp='0']" use="@name"/>

<xsl:variable name="look" select="key('kSkips',$name,$doc)"/>

If you are only concatenating them for the key lookup that's an
expensive way to do it (unless your processor internally manages to
avoid copying all the nodes).

If I have a template matching an attribute, and producing one in the output tree, like this:

  <xsl:template match="@style">
        <xsl:attribute name="style" select="."/>
  </xsl:template>

Is there any way to know the name of the element in the result tree which is the parent of the attribute being created?

Michael Kay
Saxonica

If I have a template matching an attribute, and producing one in the output tree, like this:

  <xsl:template match="@style">
        <xsl:attribute name="style" select="."/>
  </xsl:template>

  <xsl:template match="@style">
     <xsl:copy-of select="."/>
  </xsl:template>

Is there any way to know the name of the element in the result tree which is the parent of the attribute being created?

Some context: I'm turning TEI @style attributes into HTML @style attributes in the output, and I'd like to handle situations in which this kind of input:

<hi rend="text-align: center;">Centred text</hi>

results in output that doesn't work:

<span style="text-align: center;">NOT centred because it's a span</span>

If I knew the output element was a <span> or element which is inline by default, I could add "display: block" automatically to any @style attribute that contains a block-level CSS property such as text-align. I don't want to add "display: block" in all cases, because e.g. a <div> element might already have a class which floats it.

  <xsl:template match="some-block-element">
    <div>
      <xsl:apply-templates>
        <xsl:with-param name="in-a-div" tunnel="yes" select="true()"/>
      </xsl:apply-templates>
    </div>
  </xsl:template>

  <xsl:template match="@style">
    <xsl:param name="in-a-div" tunnel="yes" select="false()"/>
    <xsl:attribute name="style"
      select="concat(.,if( $in-a-div ) then ';display:block' else'')"/>
    </xsl:attribute>
  </xsl:template>

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

On Fri, Mar 22, 2013 at 2:14 PM, Martin Holmes <mholmes@xxxxxxx> wrote:
> If I have a template matching an attribute, and producing one in the output
> tree, like this:
>
>   <xsl:template match="@style">
>         <xsl:attribute name="style" select="."/>
>   </xsl:template>
>
> Is there any way to know the name of the element in the result tree which is
> the parent of the attribute being created?
>
> Some context: I'm turning TEI @style attributes into HTML @style attributes
> in the output, and I'd like to handle situations in which this kind of
> input:
>
> <hi rend="text-align: center;">Centred text</hi>
>
> results in output that doesn't work:
>
> <span style="text-align: center;">NOT centred because it's a span</span>
>
> If I knew the output element was a <span> or element which is inline by
> default, I could add "display: block" automatically to any @style attribute
> that contains a block-level CSS property such as text-align. I don't want to
> add "display: block" in all cases, because e.g. a <div> element might
> already have a class which floats it.
>
> Cheers,
> Martin

A two-stage stylesheet pipeline would work, provided that the context
you need is either *all* from the original document or *all* from the
result document (but not pieces/parts from each). (Also provided no
particular resource constraint.)
Might also be stylistically better than munging it all into one
stylesheet, if doing so separates different components of the
presentation.

-Brian

  <xsl:template match="@style">
        <xsl:attribute name="style" select="."/>
  </xsl:template>

Cheers,
Martin

> <xsl:template name="title">
>   <xsl:param name="mode" select=" 'default' " as="xs:string" />
>   <xsl:choose test="$mode eq 'index'>
>     . . .
>   </xsl:choose>

: )  Liam will have meant xsl:when test (wrapped in xsl:choose)

>   <xsl:otherwise>
>     <xsl:call-template name="process-contents">
>       <xsl:with-param name="input" select="node()" />

and that could be an apply-templates with a tunnelled param.



-- 
Andrew Welch
http://andrewjwelch.com

On Tue, 2013-03-19 at 08:58 +0000, Ihe Onwuka wrote:
> Suppose there was a genuine use case for modes. By genuine I mean the
> transform requires me to process the same nodes more than once and in
> different ways.
> 
> Can I do this without using modes.

Yes, but not in he way you describe, and not easily.

For example, you can pass a parameter to every template and have the
contents of every template wrapped inside an xsl:choose. Essentially you
end up duplicating the mode mechanism of apply-templates, though, with a
lot of inconvenience. Here's a snippet of one possible approach.

<xsl:template name="title">
  <xsl:param name="mode" select=" 'default' " as="xs:string" />
  <xsl:choose test="$mode eq 'index'>
    . . .
  </xsl:choose>
  <xsl:otherwise>
    <xsl:call-template name="process-contents">
      <xsl:with-param name="input" select="node()" />
      <xsl:with-param name="mode" select="$mode" />
    </xsl:call-template>
  </xsl:otherwise>
</xsl:template>

and so on.

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

   Hi,

This is an attempt to formalize my experience with a design pattern
that I call 3D XSLT, which consists in feeding an extra document to
the transformation with elements that carry no information but their
name, for the sole purpose of rule-based matching. I'd be glad to
gather feedback and alternatives to this approach.

While baking [1] a web site, generating in advance all the HTML pages
from a database of manga titles and authors in XML format, I felt the
need to introduce an extra dimension to the transformation.

What I mean by dimension is a vector that directs the flow of the data
transformation in a direction. There are typically two in rule-based
transformations:

* the select attribute of xsl:for-each and xsl:apply-templates,
associated with the match attribute of xsl:template
* the mode attribute of xsl:apply-templates, associated with the mode
attribute of xsl:template

I am used to the combination of match and mode, or 2D XSLT, to make
the input data bounce left and right multiple times until reaching the
expected output. For complex transformations, I further divide the
transformation into several steps, each step adding an extra layer of
decoration on top of the same data:

* Open Document Format Spreadsheet XML -> XML -> XML -> XML -> XHTML

For the final transformation from XML to XHTML, I chose to use
xsl:result-document to generate all the HTML pages from a single
transformation, rather than running a separate transformation to
generate each page.

I then started the development of the transformation with template rules:

- matching different parts of the input data for different types of pages

  * / for the home page,
  * mangaxml:manga for the page with the details of the manga

- using different modes to generate different parts of each page:

  * mode="uri" for the relative URL of the page
  * mode="title" for the title of the page
  * mode="navigation" for the navigation tabs
  * mode="contents" for the main contents
  * mode="preview" for a short preview linking to a page with details

This approach fell short when developing the transformation further to
generate additional types of pages ; several pages would correspond to
the same input data, and thus, the type of elements was no longer
sufficient to cover all cases; an extra dimension of variability was
needed:

  * / for both home page and faq page as well as other pages with
static contents
  * mangaxml:mangas for the different pages with lists of mangas by
country, by date...

My first idea was to use modes for two dimensions, both for the types
of pages and the parts of pages, but I encountered two issues which
made it too complex to be suitable:

  * although a template can match multiple modes, xsl:apply-templates
can only select a single mode at once
  * the mode parameter does not accept an expression to change the
mode using the value of a parameter

Although impracticable, this idea lead me to the solution that I
actually implemented: I introduced an extra input document with
elements that play the role of modes for the transformation:

  * <site:page name="glossary" /> instead of mode="glossary"
  * <site:page name="faq" /> instead of mode="faq"
  * <site:page name="creation-country" /> instead of mode="creation-country"
  * <site:page name="creation-date" /> instead of mode="creation-date"
  * <site:page name="manga" /> instead of mode="manga"

and while writing these lines, it occurred to me that the following
form may have made the concept more explicit:

  * <mode:glossary /> instead of mode="glossary"
  * <mode:faq /> instead of mode="faq"
  * <mode:creation-country /> instead of mode="creation-country"
  * <mode:creation-date /> instead of mode="creation-date"
  * <mode:manga /> instead of mode="manga"

The templates still have only two dimensions for rule-based matching,
mode and match, but they are applied either to a mode and a "mode
element" or to a mode and an input element, which is carried
throughout the transformations using a tunnel parameter:

<!-- context: / -->
<xsl:template match="/">
  <xsl:apply-templates mode="page"
select="$metaDoc/site:site/site:page[@name='glossary']">
    <xsl:with-param name="context" select="/" tunnel="yes" />
  </xsl:apply-templates>
  <xsl:apply-templates mode="page"
select="$metaDoc/site:site/site:page[@name='faq']">
    <xsl:with-param name="context" select="/" tunnel="yes" />
  </xsl:apply-templates>
  ...
  <xsl:apply-templates />
</xsl:template>

<!-- context: mangaxml:author -->
<xsl:template match="mangaxml:author">
  <xsl:apply-templates mode="page"
select="$metaDoc/site:site/site:page[@name='author']">
    <xsl:with-param name="context" select="." tunnel="yes" />
  </xsl:apply-templates>
</xsl:template>

...

<!--
  mode: "page" + *
  context: $context (tunnel)
-->
<xsl:template mode="page" match="site:page">
  <xsl:variable name="uri" as="xs:string">
    <xsl:apply-templates mode="uri" select="." />
  </xsl:variable>
  <!-- instructions to generate result document for each HTML page -->
</xsl:template>

<!--
  mode: "uri" + "glossary"
  context: /
-->
<xsl:template mode="uri" match="site:page[@name='glossary']">
  <!-- glossary is the home page -->
  <xsl:text>/</xsl:text>
</xsl:template>

<!--
  mode = "uri" + "faq"
  context: /
-->
<xsl:template mode="uri" match="site:page[@name='faq']">
  <xsl:text>faq/</xsl:text>
</xsl:template>

<!--
  mode = "uri" + "author"
  context: mangaxml:author
-->
<xsl:template mode="uri" match="site:page[@name='author']">
  <xsl:param name="context" as="element(mangaxml:author)" tunnel="yes" />

  <xsl:text>mangas/by/author/</xsl:text>
  <xsl:value-of select="$context/@name" />
  <xsl:text>/</xsl:text>
</xsl:template>

...

Do you have other examples of use of this pattern? Can you suggest
simpler alternatives?

Your feedback will be appreciated.

Cheers,

Eric Brichemier

--

[1] Bake, Dont Fry -  2002-07-09 by Aaron Swartz
http://www.aaronsw.com/weblog/000404

P.S. per Tommie's recommendation, please quote only the minimum amount
of my message, or reply without quoting my message, which for an
unknown reason triggers a false positive on the spam filter of the
list.

Hi,

This is an attempt to formalize my experience with a design pattern
that I call 3D XSLT, which consists in feeding an extra document to
the transformation with elements that carry no information but their
name, for the sole purpose of rule-based matching. I'd be glad to
gather feedback and alternatives to this approach.

Michael Kay
Saxonica

This is an attempt to formalize my experience with a design pattern
that I call 3D XSLT, which consists in feeding an extra document to
the transformation with elements that carry no information but their
name, for the sole purpose of rule-based matching. I'd be glad to
gather feedback and alternatives to this approach.

While baking [1] a web site, generating in advance all the HTML pages
from a database of manga titles and authors in XML format, I felt the
need to introduce an extra dimension to the transformation.

What I mean by dimension is a vector that directs the flow of the data
transformation in a direction.

Back in 2002/2003 I created a couple environments
that use a prototypical result document to direct
the flow of the transformation (if I've
understood what I've read from your post).  This
environment synthesizes XSLT stylesheets by
annotating the prototypical result document with
triggers that talk about data elements that are
feeding the creation of the result.  A process
then creates the XSLT to use against the data to mimic the prototypical
result.

Can you suggest simpler alternatives?

Perhaps these might help in some small way ... I know they have helped
others:

  http://www.CraneSoftwrights.com/resources/#literatexslt
  http://www.CraneSoftwrights.com/resources/#resultxslt

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

Suppose there was a genuine use case for modes. By genuine I mean the
transform requires me to process the same nodes more than once and in
different ways.

Can I do this without using modes.

The first thing that comes to mind is creating an separate stylesheet
for the "2nd mode" and applying it's template rules via apply-imports.

Michael Kay
Saxonica

Suppose there was a genuine use case for modes. By genuine I mean the
transform requires me to process the same nodes more than once and in
different ways.

Can I do this without using modes.

The first thing that comes to mind is creating an separate stylesheet
for the "2nd mode" and applying it's template rules via apply-imports.

The next thing that comes to mind is what if some of those rules want
to apply templates from the parent stylesheet. Well importing the
importer into the importee is not allowed but the rules don't seem to
prohibit including the importee.

So is this sufficient to dispense with modes from the subset of the
language I want to use.

Hi, 
I have got a good clue about formatting elements for worldML. In the similar
effort we need to filter these elements. Comparison of "current output" and
"desired output" is sufficient to understand the requirement.

Input
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t>Azienda</w:t></w:r>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t> </w:t></w:r>
<w:r><w:rPr><w:i/><w:b/><w:i-cs/></w:rPr><w:t>Ospedaliera</w:t></w:r>
<w:r><w:rPr><w:i/><w:b/><w:i-cs/></w:rPr><w:t>, </w:t></w:r>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t>Ospedali</w:t></w:r>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t> </w:t></w:r>
<w:proofErr w:type="spellStart"/>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t>Riuniti</w:t></w:r>

XSLT
<!--Text run container-->
 <xsl:template match="w:r">
  <xsl:choose>
   <xsl:when
test="w:rPr/w:vertAlign|w:rPr/w:u|w:rPr/w:b|w:rPr/w:i|w:rPr/w:smallCaps|w:rP
r/w:highlight">
    <xsl:apply-templates select="w:rPr" mode="styling"/>
   </xsl:when>
   <xsl:otherwise>
    <xsl:apply-templates/>
   </xsl:otherwise>
  </xsl:choose>
 </xsl:template>

<!--Text run properties container-->
 <xsl:template match="w:rPr" mode="styling">
   <xsl:for-each select="child::w:*[1]">
     <xsl:variable name="name">
       <xsl:choose>
        <xsl:when test="local-name() eq 'b'">
         <xsl:value-of select="local-name()"/>
        </xsl:when>
        <xsl:when test="local-name() eq 'i'">
         <xsl:value-of select="local-name()"/>
        </xsl:when>
      </xsl:choose>
     </xsl:variable>
     <xsl:if test="$name!=''">
      <xsl:element name="{$name}">
       <xsl:call-template name="nestedTemplate"/>
      </xsl:element>
     </xsl:if>
     <xsl:if test="$name=''">
       <xsl:call-template name="nestedTemplate"/>
     </xsl:if>
   </xsl:for-each>  
 </xsl:template>

 <xsl:template name="nestedTemplate">
   <xsl:param name="inital" select="2"/>
   <xsl:choose>
     <xsl:when test="following-sibling::w:*[$inital - 1]">
      <xsl:variable name="name">
       <xsl:choose>
        <xsl:when test="following-sibling::w:*[$inital - 1]/local-name() eq
'b'">
         <xsl:value-of select="'b'"/>
        </xsl:when>
        <xsl:when test="following-sibling::w:*[$inital - 1]/local-name() eq
'i'">
         <xsl:value-of select="'i'"/>
        </xsl:when>
       </xsl:choose>
      </xsl:variable>  
      <xsl:if test="$name!=''">  
       <xsl:element name="{$name}">
        <xsl:if test="following-sibling::w:*[$inital - 1]">
          <xsl:call-template name="nestedTemplate">
            <xsl:with-param name="inital" select="$inital + 1"/>
           </xsl:call-template>
         </xsl:if>                
       </xsl:element>
      </xsl:if>
      <xsl:if test="$name=''">  
       <xsl:if test="following-sibling::w:*[$inital - 1]">
         <xsl:call-template name="nestedTemplate">
           <xsl:with-param name="inital" select="$inital + 1"/>
          </xsl:call-template>
        </xsl:if>                
      </xsl:if>
     </xsl:when>
     <xsl:otherwise>
       <xsl:apply-templates
select="parent::w:rPr/following-sibling::w:*[1][local-name()='t']"/>
     </xsl:otherwise>
   </xsl:choose>
 </xsl:template>

Current output
<i>Azienda</i><i> </i><i><b>Ospedaliera</b></i><i><b>,
</b></i><i>Ospedali</i><i> </i><i>Riuniti</i>

Desired output
<i>Azienda <b>Ospedaliera, </b>Ospedali Riuniti</i>

Joga,
I try again.
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
    exclude-result-prefixes="xs"
version="2.0" xmlns:w="something" xmlns:tb="something-else">
    <!-- function
turns the existance or not of a w:b into something the group-adjacent can use
-->
    <xsl:strip-space elements="*"/>
    <xsl:function name="tb:switch-b">
        <xsl:param name="r"/>
        <xsl:choose>
            <xsl:when
test="boolean($r/w:rPr/w:b) = true()">1</xsl:when>
            <xsl:when
test="boolean($r/w:rPr/w:b) = false()">0</xsl:when>
        </xsl:choose>
   
</xsl:function>
   <!-- start here I put a root around the sample file called
w:p -->
    <xsl:template match="/w:p">
        <xsl:result-document
href="wordml-01-output.xml">
            <!-- with the given sample file there
will be only one group -->
            <xsl:for-each-group select="w:r"
group-adjacent="w:rPr/w:i">
                <xsl:element name="i">
                    <!-- group by bold and not bold -->
                   
<xsl:for-each-group select="current-group()/self::w:r"
group-adjacent="tb:switch-b(.)">
                        <xsl:choose>
                            <xsl:when test="current-group()//w:b">
                                <xsl:element name="b">
                                    <xsl:value-of 
select="current-group()//w:t"/>                            
                                </xsl:element>
                           
</xsl:when>
                            <xsl:otherwise>
                                <xsl:value-of  select="current-group()//w:t"/>
                            </xsl:otherwise>
                       
</xsl:choose>
                    </xsl:for-each-group>
               
</xsl:element>
            </xsl:for-each-group>
       
</xsl:result-document>
    </xsl:template>
</xsl:stylesheet>
Terry




-----
Original Message -----
From: Joga Singh Rawat <jrawat@xxxxxxxxxxxxxx>
To:
xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Cc: 
Sent: Monday, March 18, 2013 2:14 AM
Subject:  WorldML Filteration

Hi, 
I have got a good clue about
formatting elements for worldML. In the similar
effort we need to filter these
elements. Comparison of "current output" and
"desired output" is sufficient to
understand the requirement.

Input
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t>Azienda</w:t></w:r>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t> </w:t></w:r>
<w:r><w:rPr><w:i/><w:b/><w:i-cs/></w:rPr><w:t>Ospedaliera</w:t></w:r>
<w:r><w:rPr><w:i/><w:b/><w:i-cs/></w:rPr><w:t>, </w:t></w:r>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t>Ospedali</w:t></w:r>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t> </w:t></w:r>
<w:proofErr
w:type="spellStart"/>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t>Riuniti</w:t></w:r>

XSLT
<!--Text run
container-->
<xsl:template match="w:r">
  <xsl:choose>
   <xsl:when
test="w:rPr/w:vertAlign|w:rPr/w:u|w:rPr/w:b|w:rPr/w:i|w:rPr/w:smallCaps|w:rP
r/w:highlight">
    <xsl:apply-templates select="w:rPr" mode="styling"/>
 
</xsl:when>
   <xsl:otherwise>
    <xsl:apply-templates/>
   </xsl:otherwise>
  </xsl:choose>
</xsl:template>

<!--Text run properties container-->
<xsl:template match="w:rPr" mode="styling">
   <xsl:for-each
select="child::w:*[1]">
     <xsl:variable name="name">
       <xsl:choose>
 
      <xsl:when test="local-name() eq 'b'">
         <xsl:value-of
select="local-name()"/>
        </xsl:when>
        <xsl:when
test="local-name() eq 'i'">
         <xsl:value-of select="local-name()"/>
   
    </xsl:when>
      </xsl:choose>
     </xsl:variable>
     <xsl:if
test="$name!=''">
      <xsl:element name="{$name}">
       <xsl:call-template
name="nestedTemplate"/>
      </xsl:element>
     </xsl:if>
     <xsl:if
test="$name=''">
       <xsl:call-template name="nestedTemplate"/>
   
</xsl:if>
   </xsl:for-each>  
</xsl:template>

<xsl:template
name="nestedTemplate">
   <xsl:param name="inital" select="2"/>
 
<xsl:choose>
     <xsl:when test="following-sibling::w:*[$inital - 1]">
     
<xsl:variable name="name">
       <xsl:choose>
        <xsl:when
test="following-sibling::w:*[$inital - 1]/local-name() eq
'b'">
       
<xsl:value-of select="'b'"/>
        </xsl:when>
        <xsl:when
test="following-sibling::w:*[$inital - 1]/local-name() eq
'i'">
       
<xsl:value-of select="'i'"/>
        </xsl:when>
       </xsl:choose>
     
</xsl:variable>  
      <xsl:if test="$name!=''">  
       <xsl:element
name="{$name}">
        <xsl:if test="following-sibling::w:*[$inital - 1]">
 
        <xsl:call-template name="nestedTemplate">
            <xsl:with-param
name="inital" select="$inital + 1"/>
           </xsl:call-template>
       
</xsl:if>                
       </xsl:element>
      </xsl:if>
      <xsl:if
test="$name=''">  
       <xsl:if test="following-sibling::w:*[$inital - 1]">
         <xsl:call-template name="nestedTemplate">
           <xsl:with-param
name="inital" select="$inital + 1"/>
          </xsl:call-template>
       
</xsl:if>                
      </xsl:if>
     </xsl:when>
   
<xsl:otherwise>
       <xsl:apply-templates
select="parent::w:rPr/following-sibling::w:*[1][local-name()='t']"/>
   
</xsl:otherwise>
   </xsl:choose>
</xsl:template>

Current output
<i>Azienda</i><i> </i><i><b>Ospedaliera</b></i><i><b>,
</b></i><i>Ospedali</i><i> </i><i>Riuniti</i>

Desired output
<i>Azienda
<b>Ospedaliera, </b>Ospedali Riuniti</i>

Joga,
Try this - it much more fun with groups and functions and it does work
for the sample provided:
Terry<?xml version="1.0" encoding="UTF-8"?>



From:
Joga Singh Rawat <jrawat@xxxxxxxxxxxxxx>
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Sent: Monday, March 18, 2013 2:14 AM
Subject:  WorldML Filteration

Hi,
I have got a good clue about formatting elements for worldML. In the similar
effort we need to filter these elements. Comparison of "current output" and
"desired output" is sufficient to understand the requirement.

Input
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t>Azienda</w:t></w:r>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t> </w:t></w:r>
<w:r><w:rPr><w:i/><w:b/><w:i-cs/></w:rPr><w:t>Ospedaliera</w:t></w:r>
<w:r><w:rPr><w:i/><w:b/><w:i-cs/></w:rPr><w:t>, </w:t></w:r>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t>Ospedali</w:t></w:r>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t> </w:t></w:r>
<w:proofErr
w:type="spellStart"/>
<w:r><w:rPr><w:i/><w:i-cs/></w:rPr><w:t>Riuniti</w:t></w:r>

XSLT
<!--Text run
container-->
<xsl:template match="w:r">
  <xsl:choose>
  <xsl:when
test="w:rPr/w:vertAlign|w:rPr/w:u|w:rPr/w:b|w:rPr/w:i|w:rPr/w:smallCaps|w:rP
r/w:highlight">
    <xsl:apply-templates select="w:rPr" mode="styling"/>
 
</xsl:when>
  <xsl:otherwise>
    <xsl:apply-templates/>
  </xsl:otherwise>
 
</xsl:choose>
</xsl:template>

<!--Text run properties container-->
<xsl:template match="w:rPr" mode="styling">
  <xsl:for-each
select="child::w:*[1]">
    <xsl:variable name="name">
      <xsl:choose>
   
    <xsl:when test="local-name() eq 'b'">
        <xsl:value-of
select="local-name()"/>
        </xsl:when>
        <xsl:when
test="local-name() eq 'i'">
        <xsl:value-of select="local-name()"/>
   
    </xsl:when>
      </xsl:choose>
    </xsl:variable>
    <xsl:if
test="$name!=''">
      <xsl:element name="{$name}">
      <xsl:call-template
name="nestedTemplate"/>
      </xsl:element>
    </xsl:if>
    <xsl:if
test="$name=''">
      <xsl:call-template name="nestedTemplate"/>
   
</xsl:if>
  </xsl:for-each>  
</xsl:template>

<xsl:template
name="nestedTemplate">
  <xsl:param name="inital" select="2"/>
  <xsl:choose>
    <xsl:when test="following-sibling::w:*[$inital - 1]">
      <xsl:variable
name="name">
      <xsl:choose>
        <xsl:when
test="following-sibling::w:*[$inital - 1]/local-name() eq
'b'">
       
<xsl:value-of select="'b'"/>
        </xsl:when>
        <xsl:when
test="following-sibling::w:*[$inital - 1]/local-name() eq
'i'">
       
<xsl:value-of select="'i'"/>
        </xsl:when>
      </xsl:choose>
     
</xsl:variable>  
      <xsl:if test="$name!=''">  
      <xsl:element
name="{$name}">
        <xsl:if test="following-sibling::w:*[$inital - 1]">
 
        <xsl:call-template name="nestedTemplate">
            <xsl:with-param
name="inital" select="$inital + 1"/>
          </xsl:call-template>
       
</xsl:if>                
      </xsl:element>
      </xsl:if>
      <xsl:if
test="$name=''">  
      <xsl:if test="following-sibling::w:*[$inital - 1]">
 
      <xsl:call-template name="nestedTemplate">
          <xsl:with-param
name="inital" select="$inital + 1"/>
          </xsl:call-template>
       
</xsl:if>                
      </xsl:if>
    </xsl:when>
    <xsl:otherwise>
      <xsl:apply-templates
select="parent::w:rPr/following-sibling::w:*[1][local-name()='t']"/>
   
</xsl:otherwise>
  </xsl:choose>
</xsl:template>

Current output
<i>Azienda</i><i> </i><i><b>Ospedaliera</b></i><i><b>,
</b></i><i>Ospedali</i><i> </i><i>Riuniti</i>

Desired output
<i>Azienda
<b>Ospedaliera, </b>Ospedali Riuniti</i>
<xsl:stylesheetxmlns:xsl="http://www.w3.org/1999/XSL/Transform"xmlns:xs="http
://www.w3.org/2001/XMLSchema"
exclude-result-prefixes="xs"version="2.0"xmlns:w="something"xmlns:tb="somethi
ng-else">
<!-- function turns the existance or not of a w:b into something the
group-adjacent can use -->
<xsl:strip-spaceelements="*"/>
<xsl:functionname="tb:switch-b">
<xsl:paramname="r"/>
<xsl:choose>
<xsl:whentest="boolean($r/w:rPr/w:b) = true()">1</xsl:when>
<xsl:whentest="boolean($r/w:rPr/w:b) = false()">0</xsl:when>
</xsl:choose>
</xsl:function>
<!-- start here I put a root around the sample file called w:p
-->
<xsl:templatematch="/w:p">
<xsl:result-documenthref="wordml-01-output.xml">
<!-- with the given sample
file there will be only one group -->
<xsl:for-each-groupselect="w:r"group-adjacent="w:rPr/w:i">
<xsl:elementname="i">
<!-- group by bold and not bold -->
<xsl:for-each-groupselect="current-group()/self::w:r"group-adjacent="tb:switc
h-b(.)">
<xsl:choose>
<xsl:whentest="current-group()//w:b">
<xsl:elementname="b">
<xsl:value-ofselect="current-group()//w:t"/>
</xsl:element>
</xsl:when>
<xsl:otherwise>
<xsl:value-ofselect="current-group()//w:t"/>
</xsl:otherwise>
</xsl:choose>
</xsl:for-each-group>
</xsl:element>
</xsl:for-each-group>
</xsl:result-document>
</xsl:template>
</xsl:stylesheet>

And you will love this,
the XSLT2 solution... worth considering, no?

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="2.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    <xsl:template match="Cases/Cases">
        <Cases>
            <xsl:for-each-group select="*" group-starting-with="Category">
                <Case>
                    <xsl:copy-of select="current-group()"></xsl:copy-of>
                </Case>
            </xsl:for-each-group>
        </Cases>
    </xsl:template>

I am trying to add hierarchy to a flat structure and have it basically
working. But I am wondering if there is a way to generalize the children
that I am adding. Hopefully an example will help illustrate what I am doing.

Input:

<Cases>
        <Cases>
                <Category>Category One</Category>
                <CaseTitle>Category One Title</CaseTitle>
                <Institution>Category One Institution</Institution >
                <Author>Category One Author</Author>
                <History>Category One History</History>
                <Category>Category Two</Category>
                <CaseTitle>Category Two Title</CaseTitle>
                <Institution>Category Two Institution</Institution >
                <Author>Category Two Author</Author>
                <History>Category Two History</History>
        </Cases>
</Cases>

Output:

<Cases>
        <Case>
                <Category>Category One</Category>
                <CaseTitle>Category One Title</CaseTitle>
                <Institution>Category One Institution</Institution >
        </Case>
        <Case>
                <Category>Category Two</Category>
                <CaseTitle>Category Two Title</CaseTitle>
                <Institution>Category Two Institution</Institution >
        </Case>
</Cases>

Stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output indent="yes" />

    <xsl:template match="Cases/Cases">
    <Cases>
        <xsl:apply-templates select="Category" />
    </Cases>
    </xsl:template>

    <xsl:template match="Category">
        <Case>
            <Category><xsl:value-of select="." /></Category>
            <xsl:apply-templates
                select="following-sibling::CaseTitle
                [generate-id(preceding-sibling::Category[1])
                = generate-id(current())]" />
            <xsl:apply-templates
                select="following-sibling::Institution
                [generate-id(preceding-sibling::Category[1])
                = generate-id(current())]" />
        </Case>
    </xsl:template>

    <xsl:template match="CaseTitle">
        <xsl:copy-of select="." />
    </xsl:template>

    <xsl:template match="Institution">
        <xsl:copy-of select="." />
    </xsl:template>

</xsl:stylesheet>

I have template rules for each of the following siblings of Category and I
can add more for Author, etc., but it seems like there should be a way to
generalize this for any number of elements. Any help would be appreciated.

Rick

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

    <xsl:template match="Cases/Cases">
        <Cases>
            <xsl:apply-templates select="Category[1]" />
        </Cases>
    </xsl:template>

I am trying to add hierarchy to a flat structure and have it basically
working. But I am wondering if there is a way to generalize the children
that I am adding. Hopefully an example will help illustrate what I am doing.

Input:

<Cases>
        <Cases>
                <Category>Category One</Category>
                <CaseTitle>Category One Title</CaseTitle>
                <Institution>Category One Institution</Institution >
                <Author>Category One Author</Author>
                <History>Category One History</History>
                <Category>Category Two</Category>
                <CaseTitle>Category Two Title</CaseTitle>
                <Institution>Category Two Institution</Institution >
                <Author>Category Two Author</Author>
                <History>Category Two History</History>
        </Cases>
</Cases>

Output:

<Cases>
        <Case>
                <Category>Category One</Category>
                <CaseTitle>Category One Title</CaseTitle>
                <Institution>Category One Institution</Institution >
        </Case>
        <Case>
                <Category>Category Two</Category>
                <CaseTitle>Category Two Title</CaseTitle>
                <Institution>Category Two Institution</Institution >
        </Case>
</Cases>

Stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output indent="yes" />

    <xsl:template match="Cases/Cases">
    <Cases>
        <xsl:apply-templates select="Category" />
    </Cases>
    </xsl:template>

    <xsl:template match="Category">
        <Case>
            <Category><xsl:value-of select="." /></Category>
            <xsl:apply-templates
                select="following-sibling::CaseTitle
                [generate-id(preceding-sibling::Category[1])
                = generate-id(current())]" />
            <xsl:apply-templates
                select="following-sibling::Institution
                [generate-id(preceding-sibling::Category[1])
                = generate-id(current())]" />
        </Case>
    </xsl:template>

    <xsl:template match="CaseTitle">
        <xsl:copy-of select="." />
    </xsl:template>

    <xsl:template match="Institution">
        <xsl:copy-of select="." />
    </xsl:template>

</xsl:stylesheet>

I have template rules for each of the following siblings of Category and I
can add more for Author, etc., but it seems like there should be a way to
generalize this for any number of elements. Any help would be appreciated.

Rick

    <xsl:template match="Cases/Cases/*[not(self::Category)]">
        <xsl:copy-of select="." />
    </xsl:template>

as a simple replacement for all the sibling templates
then you don't need to add the root template I suggested

I am trying to add hierarchy to a flat structure and have it basically
working. But I am wondering if there is a way to generalize the children
that I am adding. Hopefully an example will help illustrate what I am doing.

Input:

<Cases>
        <Cases>
                <Category>Category One</Category>
                <CaseTitle>Category One Title</CaseTitle>
                <Institution>Category One Institution</Institution >
                <Author>Category One Author</Author>
                <History>Category One History</History>
                <Category>Category Two</Category>
                <CaseTitle>Category Two Title</CaseTitle>
                <Institution>Category Two Institution</Institution >
                <Author>Category Two Author</Author>
                <History>Category Two History</History>
        </Cases>
</Cases>

Output:

<Cases>
        <Case>
                <Category>Category One</Category>
                <CaseTitle>Category One Title</CaseTitle>
                <Institution>Category One Institution</Institution >
        </Case>
        <Case>
                <Category>Category Two</Category>
                <CaseTitle>Category Two Title</CaseTitle>
                <Institution>Category Two Institution</Institution >
        </Case>
</Cases>

Stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output indent="yes" />

    <xsl:template match="Cases/Cases">
    <Cases>
        <xsl:apply-templates select="Category" />
    </Cases>
    </xsl:template>

    <xsl:template match="Category">
        <Case>
            <Category><xsl:value-of select="." /></Category>
            <xsl:apply-templates
                select="following-sibling::CaseTitle
                [generate-id(preceding-sibling::Category[1])
                = generate-id(current())]" />
            <xsl:apply-templates
                select="following-sibling::Institution
                [generate-id(preceding-sibling::Category[1])
                = generate-id(current())]" />
        </Case>
    </xsl:template>

    <xsl:template match="CaseTitle">
        <xsl:copy-of select="." />
    </xsl:template>

    <xsl:template match="Institution">
        <xsl:copy-of select="." />
    </xsl:template>

</xsl:stylesheet>

I have template rules for each of the following siblings of Category and I
can add more for Author, etc., but it seems like there should be a way to
generalize this for any number of elements. Any help would be appreciated.

Rick

   <xsl:template match="/Cases">
            <xsl:apply-templates />
    </xsl:template>

   <xsl:template match="*">
        <xsl:copy-of select="." />
    </xsl:template>

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

<xsl:output indent="yes" />

    <xsl:template match="Cases/Cases">
    <Cases>
        <xsl:apply-templates select="Category" />
    </Cases>
    </xsl:template>

    <xsl:template match="Category">
        <Case>
            <Category><xsl:value-of select="." /></Category>
            <xsl:apply-templates
                select="following-sibling::CaseTitle
                [generate-id(preceding-sibling::Category[1])
                = generate-id(current())]" />
            <xsl:apply-templates
                select="following-sibling::Institution
                [generate-id(preceding-sibling::Category[1])
                = generate-id(current())]" />
        </Case>
    </xsl:template>

    <xsl:template match="CaseTitle">
        <xsl:copy-of select="." />
    </xsl:template>

    <xsl:template match="Institution">
        <xsl:copy-of select="." />
    </xsl:template>

</xsl:stylesheet>

Hi Geert,

Thank you very much for all your efforts with this. The sibling recursion
works fine. I tried the XSLT 2 solution, but it doesn't work in my
environment. I am saving XML from Windows InDesign CS6 and I am not sure
what kind of processor it uses. But your solution below is excellent. Thanks
again for your help.

Rick

-----Original Message-----
From: Geert Bormans [mailto:geert@xxxxxxxxxxxxxxxxxxx] 
Sent: Sunday, March 17, 2013 6:11 AM
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re:  Hierarchy to Flat Structure

Hi Rick,

As I said, I would use sibling recursion.

Start at the first Category element and walk the following-sibling axis,
like this

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
     xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

     <xsl:output indent="yes" />

     <xsl:template match="Cases/Cases">
         <Cases>
             <xsl:apply-templates select="Category[1]" />
         </Cases>
     </xsl:template>

     <xsl:template match="Category">
         <Case>
             <xsl:copy-of select="." />
             <xsl:apply-templates
select="following-sibling::*[1][not(self::Category)]"
mode="in-case-siblings"/>
         </Case>
         <xsl:apply-templates select="following-sibling::Category[1]"/>
     </xsl:template>

     <xsl:template match="*" mode="in-case-siblings">
         <xsl:copy-of select="." />
         <xsl:apply-templates
select="following-sibling::*[1][not(self::Category)]"
mode="in-case-siblings"/>
     </xsl:template>

     <xsl:template match="Category" mode="in-case-siblings"/>

  </xsl:stylesheet>

Cheers

Geert





At 02:57 17/03/2013, you wrote:
>I am trying to add hierarchy to a flat structure and have it basically 
>working. But I am wondering if there is a way to generalize the 
>children that I am adding. Hopefully an example will help illustrate what I
am doing.
>
>Input:
>
><Cases>
>         <Cases>
>                 <Category>Category One</Category>
>                 <CaseTitle>Category One Title</CaseTitle>
>                 <Institution>Category One Institution</Institution >
>                 <Author>Category One Author</Author>
>                 <History>Category One History</History>
>                 <Category>Category Two</Category>
>                 <CaseTitle>Category Two Title</CaseTitle>
>                 <Institution>Category Two Institution</Institution >
>                 <Author>Category Two Author</Author>
>                 <History>Category Two History</History>
>         </Cases>
></Cases>
>
>Output:
>
><Cases>
>         <Case>
>                 <Category>Category One</Category>
>                 <CaseTitle>Category One Title</CaseTitle>
>                 <Institution>Category One Institution</Institution >
>         </Case>
>         <Case>
>                 <Category>Category Two</Category>
>                 <CaseTitle>Category Two Title</CaseTitle>
>                 <Institution>Category Two Institution</Institution >
>         </Case>
></Cases>
>
>Stylesheet:
>
><?xml version="1.0" encoding="UTF-8"?>
><xsl:stylesheet version="1.0"
>     xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
>
>     <xsl:output indent="yes" />
>
>     <xsl:template match="Cases/Cases">
>     <Cases>
>         <xsl:apply-templates select="Category" />
>     </Cases>
>     </xsl:template>
>
>     <xsl:template match="Category">
>         <Case>
>             <Category><xsl:value-of select="." /></Category>
>             <xsl:apply-templates
>                 select="following-sibling::CaseTitle
>                 [generate-id(preceding-sibling::Category[1])
>                 = generate-id(current())]" />
>             <xsl:apply-templates
>                 select="following-sibling::Institution
>                 [generate-id(preceding-sibling::Category[1])
>                 = generate-id(current())]" />
>         </Case>
>     </xsl:template>
>
>     <xsl:template match="CaseTitle">
>         <xsl:copy-of select="." />
>     </xsl:template>
>
>     <xsl:template match="Institution">
>         <xsl:copy-of select="." />
>     </xsl:template>
>
></xsl:stylesheet>
>
>I have template rules for each of the following siblings of Category 
>and I can add more for Author, etc., but it seems like there should be 
>a way to generalize this for any number of elements. Any help would be
appreciated.
>
>Rick

I am trying to add hierarchy to a flat structure and have it basically
working. But I am wondering if there is a way to generalize the children
that I am adding. Hopefully an example will help illustrate what I am doing.

Input: 

<Cases>
	<Cases>
		<Category>Category One</Category>
		<CaseTitle>Category One Title</CaseTitle>
		<Institution>Category One Institution</Institution >
		<Author>Category One Author</Author>
		<History>Category One History</History>
		<Category>Category Two</Category>
		<CaseTitle>Category Two Title</CaseTitle>
		<Institution>Category Two Institution</Institution >
		<Author>Category Two Author</Author>
		<History>Category Two History</History>
	</Cases>
</Cases>

Output:

<Cases>
	<Case>
		<Category>Category One</Category>
		<CaseTitle>Category One Title</CaseTitle>
		<Institution>Category One Institution</Institution >
	</Case>
	<Case>
		<Category>Category Two</Category>
		<CaseTitle>Category Two Title</CaseTitle>
		<Institution>Category Two Institution</Institution >
	</Case>
</Cases>

Stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0"
    xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    
    <xsl:output indent="yes" />
    
    <xsl:template match="Cases/Cases">
    <Cases>
        <xsl:apply-templates select="Category" />
    </Cases>
    </xsl:template>
    
    <xsl:template match="Category">
        <Case>
            <Category><xsl:value-of select="." /></Category>
            <xsl:apply-templates
                select="following-sibling::CaseTitle
                [generate-id(preceding-sibling::Category[1])
                = generate-id(current())]" />
            <xsl:apply-templates
                select="following-sibling::Institution
                [generate-id(preceding-sibling::Category[1])
                = generate-id(current())]" />
        </Case>
    </xsl:template>
    
    <xsl:template match="CaseTitle">
        <xsl:copy-of select="." />
    </xsl:template>

    <xsl:template match="Institution">
        <xsl:copy-of select="." />
    </xsl:template>
    
</xsl:stylesheet>

I have template rules for each of the following siblings of Category and I
can add more for Author, etc., but it seems like there should be a way to
generalize this for any number of elements. Any help would be appreciated.

Rick

Hi Team,
Anybody who have an idea to handle it in the best way. I don't have any
idea, how to handling it using loop in xslt 2.0. Right now I am getting
duplicate texts

Input
  <w:r>
    <w:rPr>
      <w:b/>
      <w:i/>
      <w:u/>
    </w:rPr>
    <w:t>bold italics underline text</w:t>
  </w:r>
Output should be: <b><i><u>bold italics underline text</u></i></b>

  <w:r>
    <w:rPr>
      <w:i/>
      <w:b/>
      <w:u/>
    </w:rPr>
    <w:t>italics bold  underline text</w:t>
  </w:r>

Output should be: <i><b><u>italics bold  underline text</u></b></i>

XLSLT
<!--Text run container-->
 <xsl:template match="w:r">
  <xsl:choose>
   <xsl:when
test="w:rPr/w:vertAlign|w:rPr/w:u|w:rPr/w:b|w:rPr/w:i|w:rPr/w:smallCaps|w:rP
r/w:highlight">
    <xsl:apply-templates select="w:rPr" mode="styling"/>
   </xsl:when>
   <xsl:otherwise>
    <xsl:apply-templates/>
   </xsl:otherwise>
  </xsl:choose>
 </xsl:template>

 <!--Text run properties container-->
 <xsl:template match="w:rPr" mode="styling">
  <xsl:for-each select="w:vertAlign|w:u|w:b|w:i|w:smallCaps|w:highlight">
   <xsl:element name="{local-name()}">
     <xsl:apply-templates select="../../w:t"/>
    </xsl:element>
  </xsl:for-each>
 </xsl:template>

Hi Team,
Anybody who have an idea to handle it in the best way. I don't have any
idea, how to handling it using loop in xslt 2.0. Right now I am getting
duplicate texts

Input
   <w:r>
     <w:rPr>
       <w:b/>
       <w:i/>
       <w:u/>
     </w:rPr>
     <w:t>bold italics underline text</w:t>
   </w:r>
Output should be: <b><i><u>bold italics underline text</u></i></b>

   <w:r>
     <w:rPr>
       <w:i/>
       <w:b/>
       <w:u/>
     </w:rPr>
     <w:t>italics bold  underline text</w:t>
   </w:r>

Output should be: <i><b><u>italics bold underline text</u></b></i>

XLSLT
<!--Text run container-->
  <xsl:template match="w:r">
   <xsl:choose>
    <xsl:when
test="w:rPr/w:vertAlign|w:rPr/w:u|w:rPr/w:b|w:rPr/w:i|w:rPr/w:smallCaps|w:rP
r/w:highlight">
     <xsl:apply-templates select="w:rPr" mode="styling"/>
    </xsl:when>
    <xsl:otherwise>
     <xsl:apply-templates/>
    </xsl:otherwise>
   </xsl:choose>
  </xsl:template>

  <!--Text run properties container-->
  <xsl:template match="w:rPr" mode="styling">
   <xsl:for-each select="w:vertAlign|w:u|w:b|w:i|w:smallCaps|w:highlight">
    <xsl:element name="{local-name()}">
      <xsl:apply-templates select="../../w:t"/>
     </xsl:element>
   </xsl:for-each>
  </xsl:template>

--
Gerrit Imsieke
Geschdftsf|hrer / Managing Director
le-tex publishing services GmbH
Weissenfelser Str. 84, 04229 Leipzig, Germany
Phone +49 341 355356 110, Fax +49 341 355356 510
gerrit.imsieke@xxxxxxxxx, http://www.le-tex.de

Registergericht / Commercial Register: Amtsgericht Leipzig
Registernummer / Registration Number: HRB 24930

Geschdftsf|hrer: Gerrit Imsieke, Svea Jelonek,
Thomas Schmidt, Dr. Reinhard Vvckler

Hi,

This approach is also explored (independently) in these two articles:

http://balisage.net/Proceedings/vol8/html/Clark01/BalisageVol8-Clark01.html
http://jtei.revues.org/722

Cheers, Wendell


On Tue, Mar 12, 2013 at 5:27 PM, Philip Fearon <pgfearo@xxxxxxxxxxxxxx> wrote:
> A crude approach for collecting data on invoked templates, is to use a
> 'meta' XSLT stylesheet that modifies the XSLT you're interested in
> collecting data on. This could insert xsl:message instructions in each
> target template. You then just need to use this modified stylesheet on
> sample data.
>
> The XSLT might look something like this (this version not tested):
>
> <?xml version="1.0" encoding="utf-8"?>
> <xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> xmlns:xs="http://www.w3.org/2001/XMLSchema"
> xmlns:pxsl="http://qutoric.com/proxy-for-xsl">
>
> <xsl:namespace-alias stylesheet-prefix="pxsl" result-prefix="xsl"/>
>
> <xsl:output method="xml" indent="no"/>
>
> <xsl:template match="@* | node()">
> <xsl:copy>
> <xsl:apply-templates select="@* | node()"/>
> </xsl:copy>
> </xsl:template>
>
> <xsl:template
>
> match="xsl:template">
> <xsl:choose>
> <xsl:when test="empty(*)">
> <xsl:copy-of select="."/>
> </xsl:when>
> <xsl:otherwise>
>
> <xsl:copy>
> <xsl:apply-templates select="@*| xsl:param"/>
>
> <xsl:apply-templates select="node() except xsl:param"/>
> <xsl:variable name="msg" as="xs:string*">
> <xsl:for-each select="@*">
> <xsl:if test="name(.) = ('match','mode','name')">
> <xsl:value-of select="concat(' ', name(.),': ',.)"/>
> </xsl:if>
> </xsl:for-each>
> </xsl:variable>
> <xsl:text>&#10;</xsl:text>
> <pxsl:message>Template-Signature: <xsl:value-of select="msg"/></pxsl:message>
> <xsl:text>&#10;</xsl:text>
>
> </xsl:copy>
> </xsl:otherwise>
> </xsl:choose>
>
> </xsl:template>
>
> </xsl:stylesheet>
>
> -------------
>
> Phil Fearon
>
> On Fri, Mar 1, 2013 at 3:50 AM, John Laurence Poole <jlpoole56@xxxxxxxxx> wrote:
>> I'm resurrecting an old 2009 topic regarding
>> getting the name of a template.
>>
>> I followed Michael's suggestion below and have
>> successfully written an extension function that
>> produces the names of the template in instances
>> where the template is invoke through the
>> xsl:call-template mechanism.
>>
>> I'd be happy to provide a how-to on how I accomplished this along with
>> demonstration files if someone would like them; I suspect this is a
>> very esoteric area and there would not be any takers on my offer.
>>
>> What I would like to have is the ability to get
>> the name of a template in instances where the
>> template is invoked via the match mechanism:
>> xsl:apply-templates.  This would be for instances where
>> the template has a name attribute, e.g. name="template_ABC".  I tried
>> invoking my function similar to that below in a match situation and
>> null was returned despite the fact that the template that matched had
>> a name attribute.
>>
>> Any suggestions on how to approach this?  I'm new to studying the
>> internals of Saxon, but believe there must be some place where
>> information about the templates is stored to be accessed by the parser
>> for the match facility and that extending the properties of the
>> storage model to include a name attribute in instances where a
>> template does have a name attribute would be the way toapproach this.
>> Maybe I'm barking up the wrong tree and the matching mechanism is not
>> what I'm imagining?
>>
>> Thanks,
>>
>> John Poole
>>
>>
>> here's the message I'm following up on:
>>
>> On 2009-02-11 11:57:49  Michael Kay posted to this list:
>>
>> If you're prepared to grovel around the depths of Saxon internals, you can
>> write an extension function
>>
>>
>> public static String getTemplateName(net.sf.saxon.expr XPathContext context)
>> {
>>      try {
>>         return context.getOrigin().getObjectName().getDisplayName();
>>      } catch (Exception err) {
>>         return null;
>>      }
>> }
>>
>> and call it without any arguments as xx:getTemplateName(). Not tested. It
>> will only give the template name if it was invoked using call-template.
>> Should probably work for function calls as well.
>>
>> Michael Kay
>> http://www.saxonica.com/
>



--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^

A crude approach for collecting data on invoked templates, is to use a
'meta' XSLT stylesheet that modifies the XSLT you're interested in
collecting data on. This could insert xsl:message instructions in each
target template. You then just need to use this modified stylesheet on
sample data.

The XSLT might look something like this (this version not tested):

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pxsl="http://qutoric.com/proxy-for-xsl">

<xsl:namespace-alias stylesheet-prefix="pxsl" result-prefix="xsl"/>

<xsl:output method="xml" indent="no"/>

<xsl:template match="@* | node()">
<xsl:copy>
<xsl:apply-templates select="@* | node()"/>
</xsl:copy>
</xsl:template>

<xsl:template

match="xsl:template">
<xsl:choose>
<xsl:when test="empty(*)">
<xsl:copy-of select="."/>
</xsl:when>
<xsl:otherwise>

<xsl:copy>
<xsl:apply-templates select="@*| xsl:param"/>

<xsl:apply-templates select="node() except xsl:param"/>
<xsl:variable name="msg" as="xs:string*">
<xsl:for-each select="@*">
<xsl:if test="name(.) = ('match','mode','name')">
<xsl:value-of select="concat(' ', name(.),': ',.)"/>
</xsl:if>
</xsl:for-each>
</xsl:variable>
<xsl:text>&#10;</xsl:text>
<pxsl:message>Template-Signature: <xsl:value-of select="msg"/></pxsl:message>
<xsl:text>&#10;</xsl:text>

</xsl:copy>
</xsl:otherwise>
</xsl:choose>

</xsl:template>

</xsl:stylesheet>

-------------

Phil Fearon

On Fri, Mar 1, 2013 at 3:50 AM, John Laurence Poole<jlpoole56@xxxxxxxxx> wrote:

I'm resurrecting an old 2009 topic regarding
getting the name of a template.

I followed Michael's suggestion below and have
successfully written an extension function that
produces the names of the template in instances
where the template is invoke through the
xsl:call-template mechanism.

I'd be happy to provide a how-to on how I accomplished this along with
demonstration files if someone would like them; I suspect this is a
very esoteric area and there would not be any takers on my offer.

What I would like to have is the ability to get
the name of a template in instances where the
template is invoked via the match mechanism:
xsl:apply-templates.  This would be for instances where
the template has a name attribute, e.g. name="template_ABC".  I tried
invoking my function similar to that below in a match situation and
null was returned despite the fact that the template that matched had
a name attribute.

Any suggestions on how to approach this?  I'm new to studying the
internals of Saxon, but believe there must be some place where
information about the templates is stored to be accessed by the parser
for the match facility and that extending the properties of the
storage model to include a name attribute in instances where a
template does have a name attribute would be the way toapproach this.
Maybe I'm barking up the wrong tree and the matching mechanism is not
what I'm imagining?

Thanks,

John Poole


here's the message I'm following up on:

On 2009-02-11 11:57:49 Michael Kay posted to this list:

If you're prepared to grovel around the depths of Saxon internals, you can
write an extension function

public static String getTemplateName(net.sf.saxon.expr XPathContext context)
{
      try {
         return context.getOrigin().getObjectName().getDisplayName();
      } catch (Exception err) {
         return null;
      }
}

and call it without any arguments as xx:getTemplateName(). Not tested. It
will only give the template name if it was invoked using call-template.
Should probably work for function calls as well.

Michael Kay
http://www.saxonica.com/

--
John Lumley MA PhD CEng FIEE
john@xxxxxxxxxxxxxx

A crude approach for collecting data on invoked templates, is to use a
'meta' XSLT stylesheet that modifies the XSLT you're interested in
collecting data on. This could insert xsl:message instructions in each
target template. You then just need to use this modified stylesheet on
sample data.

The XSLT might look something like this (this version not tested):

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="2.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:pxsl="http://qutoric.com/proxy-for-xsl">

<xsl:namespace-alias stylesheet-prefix="pxsl" result-prefix="xsl"/>

<xsl:output method="xml" indent="no"/>

<xsl:template match="@* | node()">
<xsl:copy>
<xsl:apply-templates select="@* | node()"/>
</xsl:copy>
</xsl:template>

<xsl:template

match="xsl:template">
<xsl:choose>
<xsl:when test="empty(*)">
<xsl:copy-of select="."/>
</xsl:when>
<xsl:otherwise>

<xsl:copy>
<xsl:apply-templates select="@*| xsl:param"/>

<xsl:apply-templates select="node() except xsl:param"/>
<xsl:variable name="msg" as="xs:string*">
<xsl:for-each select="@*">
<xsl:if test="name(.) = ('match','mode','name')">
<xsl:value-of select="concat(' ', name(.),': ',.)"/>
</xsl:if>
</xsl:for-each>
</xsl:variable>
<xsl:text>&#10;</xsl:text>
<pxsl:message>Template-Signature: <xsl:value-of select="msg"/></pxsl:message>
<xsl:text>&#10;</xsl:text>

</xsl:copy>
</xsl:otherwise>
</xsl:choose>

</xsl:template>

</xsl:stylesheet>

-------------

Phil Fearon

On Fri, Mar 1, 2013 at 3:50 AM, John Laurence Poole <jlpoole56@xxxxxxxxx> wrote:
> I'm resurrecting an old 2009 topic regarding
> getting the name of a template.
>
> I followed Michael's suggestion below and have
> successfully written an extension function that
> produces the names of the template in instances
> where the template is invoke through the
> xsl:call-template mechanism.
>
> I'd be happy to provide a how-to on how I accomplished this along with
> demonstration files if someone would like them; I suspect this is a
> very esoteric area and there would not be any takers on my offer.
>
> What I would like to have is the ability to get
> the name of a template in instances where the
> template is invoked via the match mechanism:
> xsl:apply-templates.  This would be for instances where
> the template has a name attribute, e.g. name="template_ABC".  I tried
> invoking my function similar to that below in a match situation and
> null was returned despite the fact that the template that matched had
> a name attribute.
>
> Any suggestions on how to approach this?  I'm new to studying the
> internals of Saxon, but believe there must be some place where
> information about the templates is stored to be accessed by the parser
> for the match facility and that extending the properties of the
> storage model to include a name attribute in instances where a
> template does have a name attribute would be the way toapproach this.
> Maybe I'm barking up the wrong tree and the matching mechanism is not
> what I'm imagining?
>
> Thanks,
>
> John Poole
>
>
> here's the message I'm following up on:
>
> On 2009-02-11 11:57:49  Michael Kay posted to this list:
>
> If you're prepared to grovel around the depths of Saxon internals, you can
> write an extension function
>
>
> public static String getTemplateName(net.sf.saxon.expr XPathContext context)
> {
>      try {
>         return context.getOrigin().getObjectName().getDisplayName();
>      } catch (Exception err) {
>         return null;
>      }
> }
>
> and call it without any arguments as xx:getTemplateName(). Not tested. It
> will only give the template name if it was invoked using call-template.
> Should probably work for function calls as well.
>
> Michael Kay
> http://www.saxonica.com/

Ken,

Thanks! Indeed, the little voice in my head whispered "instance of",
but that was about 10pm my time (later than you posted) so maybe it
was reading the list.

Cheers,
Wendell


On Mon, Mar 11, 2013 at 6:36 PM, G. Ken Holman
<gkholman@xxxxxxxxxxxxxxxxxxxx> wrote:
> At 2013-03-11 18:31 -0400, Wendell Piez wrote:
>>
>> Could someone please remind me the most graceful way in XPath 2.0 of
>> determining dynamically whether any arbitrary $n is bound to a node or
>> sequence of nodes (i.e., no atomic values)?
>
>
> instance of node()*
>
>
>> There's some furious parameterization going on and I just can't
>> remember this. (It's not the kind of thing easy to search for either.)
>
>
> Not sure what you are referring to regarding parameterization.
>
> I hope the illustration below helps.
>
> . . . . . . . . Ken
>
> t:\ftemp>type wendell.xsl
> <?xml version="1.0" encoding="US-ASCII"?>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>                 version="2.0">
>
> <xsl:output method="text"/>
>
> <xsl:template match="/">
>   <xsl:variable name="test1" select="doc(''),doc('')/*/xsl:*"/>
>   <xsl:value-of select="count($test1),$test1 instance of node()*,'&#xa;'"/>
>   <xsl:variable name="test2" select="$test1,'hello',$test1"/>
>   <xsl:value-of select="count($test2),$test2 instance of node()*,'&#xa;'"/>
> </xsl:template>
>
> </xsl:stylesheet>
> t:\ftemp>xslt2 wendell.xsl wendell.xsl
> 3 true
> 7 false
>
> t:\ftemp>
>
>
> --
> Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013 |
> Contact us for world-wide XML consulting and instructor-led training |
> Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
> Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
> G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
> Google+ profile: https://plus.google.com/116832879756988317389/about |
> Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |
>



--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^

At 2013-03-11 18:31 -0400, Wendell Piez wrote:

Could someone please remind me the most graceful way in XPath 2.0 of
determining dynamically whether any arbitrary $n is bound to a node or
sequence of nodes (i.e., no atomic values)?

instance of node()*

There's some furious parameterization going on and I just can't
remember this. (It's not the kind of thing easy to search for either.)

Not sure what you are referring to regarding parameterization.

I hope the illustration below helps.

. . . . . . . . Ken

t:\ftemp>type wendell.xsl
<?xml version="1.0" encoding="US-ASCII"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                version="2.0">

<xsl:output method="text"/>

<xsl:template match="/">
  <xsl:variable name="test1" select="doc(''),doc('')/*/xsl:*"/>
  <xsl:value-of select="count($test1),$test1 instance of node()*,'&#xa;'"/>
  <xsl:variable name="test2" select="$test1,'hello',$test1"/>
  <xsl:value-of select="count($test2),$test2 instance of node()*,'&#xa;'"/>
</xsl:template>

</xsl:stylesheet>
t:\ftemp>xslt2 wendell.xsl wendell.xsl
3 true
7 false

t:\ftemp>

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

Could someone please remind me the most graceful way in XPath 2.0 of
determining dynamically whether any arbitrary $n is bound to a node or
sequence of nodes (i.e., no atomic values)?

There's some furious parameterization going on and I just can't
remember this. (It's not the kind of thing easy to search for either.)

t:\ftemp>type wendell.xsl
<?xml version="1.0" encoding="US-ASCII"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
                version="2.0">

<xsl:template match="/">
  <xsl:variable name="test1" select="doc(''),doc('')/*/xsl:*"/>
  <xsl:value-of select="count($test1),$test1 instance of node()*,'&#xa;'"/>
  <xsl:variable name="test2" select="$test1,'hello',$test1"/>
  <xsl:value-of select="count($test2),$test2 instance of node()*,'&#xa;'"/>
</xsl:template>

</xsl:stylesheet>
t:\ftemp>xslt2 wendell.xsl wendell.xsl
3 true
7 false

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

Friends,

Could someone please remind me the most graceful way in XPath 2.0 of
determining dynamically whether any arbitrary $n is bound to a node or
sequence of nodes (i.e., no atomic values)?

There's some furious parameterization going on and I just can't
remember this. (It's not the kind of thing easy to search for either.)

Cheers,
Wendell

-- 
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^

I am conducting research on real-world JSON and XML browser performance.
This is the first public beta of the test and I would appreciate anyone with a
few minutes to give it a try and send me comments.
( Note: This test is NOT intended to test everything  ... it's a focused test
with a few controlled variables).

What You Do

Go to
   http://speedtest.xmlsh.org

Click "Run Tests And Submit..."
Test takes about 1 - 3 minutes depending on your internet and device speed.

Repeat as often as have patience on as many difference OS's, machines, browser
vendors and versions and devices.
I am particularly interested in mobile devices as these have had much less
coverage in these kinds of experiments, but anything you can try is valuable.

Please feel free to pass this link on ... I will be updating the tests pending
comments of this initial public beta and then intend on distributing the test
to a wider audience (including full source).

The results are intended to be published publicly after enough data collection
and analysis has been completed.

Thank you for any assistance and comments.



----------------------------------------
David A. Lee
dlee@xxxxxxxxxxx
http://www.xmlsh.org


----------------------------------------
David A. Lee
dlee@xxxxxxxxxxx
http://www.xmlsh.org

See inline.

On 09/03/2013, Graydon <graydon@xxxxxxxxx> wrote:
> On Sat, Mar 09, 2013 at 05:02:19PM +0100, Wolfgang Laun scripsit:
>> XSLT 2.0.
>>
>> I had to create a single document from several inputs (so that a key
>> lookup could access them all with a single call):
>>
>> <xsl:variable name="doc" as="document-node()">
>>  <xsl:document>
>>    <xsl:sequence select="document($paths)/*"/>
>>  </xsl:document>
>> </xsl:variable>
>>  <xsl:key name="kSkips"
>>          match="element()[@omc:ilp='0']"
>>          use="@name"/>
>>
>>  <xsl:variable name="look" select="key('kSkips',$name,$doc)"/>
>>
>> What surprised me was that I could use
>>  <xsl:sequence select="document($paths)"/>
>> without an error, which would make the document-nodes of the inputs
>> children of the temporary document-node. Is the XSL processor clever
>
> Betcha you can't.
What, exactly? Both forms - with and without '/*' - appear to work
correctly - at least the key() function delivers.

>
> Once you've gone
>
> <xsl:sequence select="document($paths)/*"/>
>
> It's not document nodes anymore.

That I realized and thought advisable while I put them under the new
temporary document-node.

I just wondered why I don't have to select the document-nodes' *children*.

-W

> -- Graydon

XSLT 2.0.

I had to create a single document from several inputs (so that a key
lookup could access them all with a single call):

<xsl:variable name="doc" as="document-node()">
 <xsl:document>
   <xsl:sequence select="document($paths)/*"/>
 </xsl:document>
</xsl:variable>
 <xsl:key name="kSkips"
         match="element()[@omc:ilp='0']"
         use="@name"/>

 <xsl:variable name="look" select="key('kSkips',$name,$doc)"/>

What surprised me was that I could use
 <xsl:sequence select="document($paths)"/>
without an error, which would make the document-nodes of the inputs
children of the temporary document-node. Is the XSL processor clever
enough to handle this? Where can I find more information about this?

Thanks for enhancing my education ;-)
Wolfgang

On Sat, Mar 09, 2013 at 05:30:11PM +0100, Wolfgang Laun scripsit:
> See inline.
> On 09/03/2013, Graydon <graydon@xxxxxxxxx> wrote:
> > On Sat, Mar 09, 2013 at 05:02:19PM +0100, Wolfgang Laun scripsit:
[snip]
> >> What surprised me was that I could use
> >>  <xsl:sequence select="document($paths)"/>
> >> without an error, which would make the document-nodes of the inputs
> >> children of the temporary document-node. Is the XSL processor clever
> >
> > Betcha you can't.
> What, exactly? Both forms - with and without '/*' - appear to work
> correctly - at least the key() function delivers.

Which surprised me, because I wouldn't have expected 

<xsl:sequence select="document($paths)"/>

to work, then I went and looked at the spec for the surrounding
xsl:document, an instruction I don't think I've ever used.

> I just wondered why I don't have to select the document-nodes' *children*.

Sequence constructor rules, item 4 -- 

http://www.w3.org/TR/xslt20/#constructing-complex-content

"Any document node within the result sequence is replaced by a sequence
containing each of its children, in document order."

So you just can't put a document node in a document node via any
sequence constructor, which makes sense.

So, yes, processor _has_ to be clever enough, it's in the spec. :)

-- Graydon

On Sat, Mar 09, 2013 at 05:02:19PM +0100, Wolfgang Laun scripsit:
> XSLT 2.0.
> 
> I had to create a single document from several inputs (so that a key
> lookup could access them all with a single call):
> 
> <xsl:variable name="doc" as="document-node()">
>  <xsl:document>
>    <xsl:sequence select="document($paths)/*"/>
>  </xsl:document>
> </xsl:variable>
>  <xsl:key name="kSkips"
>          match="element()[@omc:ilp='0']"
>          use="@name"/>
> 
>  <xsl:variable name="look" select="key('kSkips',$name,$doc)"/>
> 
> What surprised me was that I could use
>  <xsl:sequence select="document($paths)"/>
> without an error, which would make the document-nodes of the inputs
> children of the temporary document-node. Is the XSL processor clever

Betcha you can't.

Once you've gone

<xsl:sequence select="document($paths)/*"/>

It's not document nodes anymore.  Same as 

<xsl:for-each select="collection()/*">

doesn't give the document nodes and

<xsl:for-each select="collection()">

does.

-- Graydon

Karl,

I think we managed to stick close enough to XSL to make it count.

It's understandable that the database guys feel that the system should
guard against bad data in the front. But this becomes a UI issue and
(when it comes to database front ends) that can be sticky.

Notepad++ has been recommended to me by a number of happy users. And
you've probably found the XML support available for it.

Cheers, Wendell


On Tue, Mar 5, 2013 at 5:13 PM, Karlmarx R <karlmarxr@xxxxxxxxx> wrote:
> Hi Wendell,
>
> Thanks again for the additional information. Sorry for my delayed response.
I tried to get additional info, but unable to obtain so far. So, to answer
some of questions:
>>are they really not "technical"?
> Not exactly. Mixed lot. But XML and its technology are new to them and
moreover I found a resistance to learn or look beyond their own technology and
hence I mentioned non-tech to make it easy to the list.
>
>>What sorts of applications do your non-technical users already know and like
to use? What operating systems are they running?
> Some are from academic background who adds details to via UI - the db being
oracle but they don't have to worry about db. I know these people often copy
paste things from word doc etc., that include bullet points etc. and so
whatever diff sort of stuffs go into the db. There are two tech people who
look into oracle, running in UNIX server. I was told that they use some oracle
function to specify what fields are to be extracted (as XML) and that internal
function delivers the XML output - in tech terms this turned out  "not to be
an XML" due to content issues..
>
> Regarding editors, I think they are now happy with notepad++ and I have
anyway suggested other options discussed in the earlier threads, incl your
last one.
>
> I think their problem seems more of internal issue. The oracle guys want the
academics to enter correct data and take ownership. But everyone (except the
oracle guys!) understands that that is not going to happen anytime soon, if at
all it happens. So, the internal clash of who take data cleaning
responsibility somehow ended up with "XML-XSL" as the target. But I think they
now had consensus to look from all front, mainly oracle side to see a way to
filter out unwanted entities and chars. So, pretty much resolved I would say.
And you are right that the discussion did resulted in some interesting
informations.
>
>
> Thanks again. Kind regards.
>



--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^

Hi Wendell, 

Thanks again for the additional information. Sorry for my
delayed response. I tried to get additional info, but unable to obtain so far.
So, to answer some of questions:
>are they really not "technical"?
Not
exactly. Mixed lot. But XML and its technology are new to them and moreover I
found a resistance to learn or look beyond their own technology and hence I
mentioned non-tech to make it easy to the list.

>What sorts of applications
do your non-technical users already know and like to use? What operating
systems are they running?
Some are from academic background who adds details
to via UI - the db being oracle but they don't have to worry about db. I know
these people often copy paste things from word doc etc., that include bullet
points etc. and so whatever diff sort of stuffs go into the db. There are two
tech people who look into oracle, running in UNIX server. I was told that they
use some oracle function to specify what fields are to be extracted (as XML)
and that internal function delivers the XML output - in tech terms this turned
out  "not to be an XML" due to content issues.. 

Regarding editors, I think
they are now happy with notepad++ and I have anyway suggested other options
discussed in the earlier threads, incl your last one.

I think their problem
seems more of internal issue. The oracle guys want the academics to enter
correct data and take ownership. But everyone (except the oracle guys!)
understands that that is not going to happen anytime soon, if at all it
happens. So, the internal clash of who take data cleaning responsibility
somehow ended up with "XML-XSL" as the target. But I think they now had
consensus to look from all front, mainly oracle side to see a way to filter
out unwanted entities and chars. So, pretty much resolved I would say. And you
are right that the discussion did resulted in some interesting informations.
Thanks again. Kind regards.

I have just encountered a stylesheet

<element url='bob'>
   <xsl:attribute name="url" select="'somethingotherthanbob'">
</element>

which should take precedence?

I have just encountered a stylesheet

<element url='bob'>
   <xsl:attribute name="url" select="'somethingotherthanbob'">
</element>

which should take precedence?

  - first any xsl:use-attribute-sets= references
  - then any specified attributes
  - then any <xsl:attribute> instructions

--
Public XSLT, XSL-FO, UBL and code list classes in Europe -- Apr 2013 |
Contact us for world-wide XML consulting and instructor-led training |
Free 5-hour lecture: http://www.CraneSoftwrights.com/links/udemy.htm |
Crane Softwrights Ltd.            http://www.CraneSoftwrights.com/s/ |
G. Ken Holman                   mailto:gkholman@xxxxxxxxxxxxxxxxxxxx |
Google+ profile: https://plus.google.com/116832879756988317389/about |
Legal business disclaimers:    http://www.CraneSoftwrights.com/legal |

Thanks to you all for the various answers and suggestions. Very useful. Thanks
again.

Regards.

Karl,

You're very welcome, and I apologize if I came off as abrupt about the
OT-ness. Just because your question was off topic does not (at all!)
mean it was not of interest to readers of this list.

You may want to consider a range of options, for your gatekeepers to
use according to personal preference. If they use text editors, they
can learn to use XML editors or XML add-ons to the their text editors.
Liam mentioned xmllint and there are other command-line options. Maybe
they would be interested in xmlsh, a set of utilities in the form of a
shell. Etc. If you encourage them to try a few different things you
might be able to get them to teach each other.

If they are really not "technical" (which can mean a lot of things, as
there are many ways to be technical than to be expert with computers
:-) they may be most at home with one of the lightweight editors you
can find on line.

Undertaking a survey of the present state of the art in XML editors at
the free or low-cost end would -- again -- be off-topic ...

... unless it were reframed as "what's the state of the art in
low-cost or free editing applications to enable 'non-technical' users
to correct broken 'XML' and fix it for XSLT" ... one might manage to
get that on topic by stressing the last point. :->

What sorts of applications do your non-technical users already know
and like to use? What operating systems are they running?

Are they already viewing the XML in a styled display through CSS or
XSLT? Have they ever seen angle brackets?

Cheers, Wendell




On Sat, Mar 2, 2013 at 6:32 AM, Karlmarx R <karlmarxr@xxxxxxxxx> wrote:
> Thanks to you all for the various answers and suggestions. Very useful. Thanks again.
>
> Regards.
>



--
Wendell Piez | http://www.wendellpiez.com
XML | XSLT | electronic publishing
Eat Your Vegetables
_____oo_________o_o___ooooo____ooooooo_^

> For example, there's a sorry history of patches to the spec regarding the
> handling of a newline character appearing as the last thing in the input.
>
yeah, negative lookahead assertions can be really handy.

<xsd:pattern value="\d"/>
defines as a single digit, and should not match eg. "7\n".

The PCRE regexp "^\d$" does match "7" as well as "7\n".

"^\d(?!\n)$" does only match a single digit.



Mit besten Gruessen / Best wishes,

Hermann Stamm-Wilbrandt
Level 3 support for XML Compiler team and Fixpack team lead
WebSphere DataPower SOA Appliances
https://www.ibm.com/developerworks/mydeveloperworks/blogs/HermannSW/
https://twitter.com/HermannSW/
----------------------------------------------------------------------
IBM Deutschland Research & Development GmbH
Vorsitzende des Aufsichtsrats: Martina Koederitz
Geschaeftsfuehrung: Dirk Wittkopp
Sitz der Gesellschaft: Boeblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294


|------------>
| From:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Michael Kay <mike@xxxxxxxxxxxx>                                                                                                                   |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| To:        |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |xsl-list@xxxxxxxxxxxxxxxxxxxxxx,                                                                                                                  |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Date:      |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |03/01/2013 11:40 AM                                                                                                                               |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
|------------>
| Subject:   |
|------------>
  >--------------------------------------------------------------------------------------------------------------------------------------------------|
  |Re:  Support for lookaround regexp in XSLT -- any time soon?                                                                                 |
  >--------------------------------------------------------------------------------------------------------------------------------------------------|







>unsure about the original reason to restrict regex, as it seems to
just confuse people when a regex they lovingly crafted elsewhere
doesn't work (not that the various java, Perl, etc schisms help).

I don't know the history in full, but I think there were several reasons
XSD adopted a "minimal" regex subset:

(a) they wanted to be sure it could be widely implemented using existing
regex engines (i.e. a highest common factor approach)

(b) they wanted to exclude anything that didn't make sense in an
international Unicode context (so things like word boundaries were
immediately suspect)

(c) they wanted to make sure that what they included was well specified.
Finding solid specifications of regex constructs is remarkably difficult;
there's a culture of very informal specification. Many times when adding
constructs to the XPath spec, we've had to do empirical tests on existing
regex engines such as PCRE to see how they actually handle edge cases, and
very often we find differences between different engines that couldn't be
guessed from the documentation. For example, there's a sorry history of
patches to the spec regarding the handling of a newline character appearing
as the last thing in the input. It's a shame when a feature gets left out
because we can't decide what it should do in edge cases, but the standards
process tends to lead to people asking such questions and expecting
answers.

Michael Kay
Saxonica

Should have said I'm doing this in XSLT. I can use keys, but I'm trying to
figure out the XPath to make the keys useful.

I have the following XML:

<wrapper>
<object class="Page" package="com.atlassian.confluence.pages">
	<id name="id">37716253</id>
	<property name="title">
		<![CDATA[COMPARE]]>
	</property>
	...
	<property name="version">3</property>
	<property name="creatorName">
		<![CDATA[wbenica]]>
	</property>
	<property name="creationDate">2012-11-16 14:00:35.000</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
	<id name="id">37716529</id>
	<property name="title">
		<![CDATA[COMPARE]]>
	</property>
	...
	<property name="version">1</property>
	<property name="creatorName">
		<![CDATA[wbenica]]>
	</property>
	<property name="creationDate">2012-11-16 14:00:35.000</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
	<id name="id">37716528</id>
	<property name="title">
		<![CDATA[COMPARE]]>
	</property>
	...
	<property name="version">2</property>
	<property name="creatorName">
		<![CDATA[wbenica]]>
	</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
	<id name="id">37716253</id>
	<property name="title">
		<![CDATA[SOME OTHER TITLE]]>
	</property>
	...
	<property name="version">3</property>
	<property name="creatorName">
		<![CDATA[wbenica]]>
	</property>
	<property name="creationDate">2012-11-16 14:00:35.000</property>
</object>
</wrapper>

I want to find the <id> element value for the <object> element that has
the highest version <property> (of those matching the title) and matches the
title <property> element for 'COMPARE'.

The following matchs all <object>
elements that have a title and version:

//object[property[@name='title'] and property[@name='version']]

How do I look for a specific title and find the highest version? Is it
possible in one XPath statement?

ok I redact the unambiguous part ... was getting nostalgic.

though sometimes ... I do feel that we rush to specify in language
that machines understand first, personally I like the fireside chat
approach but acknowledge I wouldn't want to build a rocket ship with
this level of 'blueprint'.

J






On Fri, Mar 1, 2013 at 6:39 PM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
>
>
>> but I would argue that perl6
>
>
>> https://github.com/perl6/specs/blob/master/S05-regex.pod
>
>
>> does the best job at unambiguously defining ...
>
>
> That's supposed to be unambiguous? It's a fireside chat, full of "Oh, and
> here's something else I thought I might mention".
>
>
> Michael Kay
> Saxonica

On Fri, 2013-03-01 at 14:38 -0800, dvint@xxxxxxxxx wrote:
> I have the following XML:
[...]

> <object class="Page" package="com.atlassian.confluence.pages">
> 	<id name="id">37716253</id>
> 	<property name="title">
> 		<![CDATA[SOME OTHER TITLE]]>
> 	</property>
> 	...
> 	<property name="version">3</property>
> 	<property name="creatorName">
> 		<![CDATA[wbenica]]>
> 	</property>
> 	<property name="creationDate">2012-11-16 14:00:35.000</property>
> </object>
> </wrapper>
> 
> I want to find the <id> element value for the <object> element that has
> the highest version <property> (of those matching the title) and matches the
> title <property> element for 'COMPARE'.

You mentioned elsewhere that you're using XSLT but not which version.

Here's an XQuery version:

(for $i in //object[match title here]
  order by property[@name eq "version"] descending
  return $i)[1]/id

David already suggested a way to match title elements.

In XPath we can do something like this, looking for an object such that
no other object has a higher version (assuming they all have versions):

//object[
  not(
   //object[property[@name eq "version"] > property[@name eq "version"]
  )]/id

but it might not be very fast...

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

thx for the background info, its useful and interesting to hear about.

btw

    http://en.wikipedia.org/wiki/Regular_expression

does a good job at identifying regex specs/docs

but I would argue that perl6

https://github.com/perl6/specs/blob/master/S05-regex.pod

does the best job at unambiguously defining ... though this regex is
not your grandad's regex.

back to regex in XML land ... to add a datapoint: I think the only oft
repeated shortcoming of regex in XML, is lack of lookahead/lookbehind

J



On Fri, Mar 1, 2013 at 11:40 AM, Michael Kay <mike@xxxxxxxxxxxx> wrote:
>
>
>> unsure about the original reason to restrict regex, as it seems to
>
> just confuse people when a regex they lovingly crafted elsewhere
> doesn't work (not that the various java, Perl, etc schisms help).
>
> I don't know the history in full, but I think there were several reasons XSD
> adopted a "minimal" regex subset:
>
> (a) they wanted to be sure it could be widely implemented using existing
> regex engines (i.e. a highest common factor approach)
>
> (b) they wanted to exclude anything that didn't make sense in an
> international Unicode context (so things like word boundaries were
> immediately suspect)
>
> (c) they wanted to make sure that what they included was well specified.
> Finding solid specifications of regex constructs is remarkably difficult;
> there's a culture of very informal specification. Many times when adding
> constructs to the XPath spec, we've had to do empirical tests on existing
> regex engines such as PCRE to see how they actually handle edge cases, and
> very often we find differences between different engines that couldn't be
> guessed from the documentation. For example, there's a sorry history of
> patches to the spec regarding the handling of a newline character appearing
> as the last thing in the input. It's a shame when a feature gets left out
> because we can't decide what it should do in edge cases, but the standards
> process tends to lead to people asking such questions and expecting answers.
>
> Michael Kay
> Saxonica

but I would argue that perl6

https://github.com/perl6/specs/blob/master/S05-regex.pod

does the best job at unambiguously defining ...

Michael Kay
Saxonica

> for $m in
>
max(//object[normalize-space(property[@name='title'])='COMPARE']/number(prope
rty[@name='version']))
> return
>
//object[normalize-space(property[@name='title'])='COMPARE'][number(property[
@name='version'])=$m]/id


Should have said I'm doing this in XSLT. I can use keys, but I'm trying to
figure out the XPath to make the keys useful.

>
>
>
> (more pointless CDATA markup in your input document)

Agreed, but I can't change that as it is what the 3rd party app is
creating. I suppose it might be easier to preproces this single input file
before I produce the files I need. That would allow me easier access to
some information.

..dan


>
> David

I have the following XML:

<wrapper>
<object class="Page" package="com.atlassian.confluence.pages">
	<id name="id">37716253</id>
	<property name="title">
		<![CDATA[COMPARE]]>
	</property>
	...
	<property name="version">3</property>
	<property name="creatorName">
		<![CDATA[wbenica]]>
	</property>
	<property name="creationDate">2012-11-16 14:00:35.000</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
	<id name="id">37716529</id>
	<property name="title">
		<![CDATA[COMPARE]]>
	</property>
	...
	<property name="version">1</property>
	<property name="creatorName">
		<![CDATA[wbenica]]>
	</property>
	<property name="creationDate">2012-11-16 14:00:35.000</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
	<id name="id">37716528</id>
	<property name="title">
		<![CDATA[COMPARE]]>
	</property>
	...
	<property name="version">2</property>
	<property name="creatorName">
		<![CDATA[wbenica]]>
	</property>
</object>
<object class="Page" package="com.atlassian.confluence.pages">
	<id name="id">37716253</id>
	<property name="title">
		<![CDATA[SOME OTHER TITLE]]>
	</property>
	...
	<property name="version">3</property>
	<property name="creatorName">
		<![CDATA[wbenica]]>
	</property>
	<property name="creationDate">2012-11-16 14:00:35.000</property>
</object>
</wrapper>

I want to find the <id> element value for the <object> element that has
the highest version <property> (of those matching the title) and matches the
title <property> element for 'COMPARE'.

The following matchs all <object>
elements that have a title and version:

//object[property[@name='title'] and property[@name='version']]

How do I look for a specific title and find the highest version? Is it
possible in one XPath statement?

(b) they wanted to exclude anything that didn't make sense in an
international Unicode context (so things like word boundaries were
immediately suspect)

On 01.03.2013 11:40, Michael Kay wrote:

(b) they wanted to exclude anything that didn't make sense in an
international Unicode context (so things like word boundaries were
immediately suspect)

If they had been concerned about what is a word constituent and what is not in a certain language, they wouldnbt have included \w and \W in http://www.w3.org/TR/xmlschema-2/#cces

Michael Kay
Saxonica

unsure about the original reason to restrict regex, as it seems to

just confuse people when a regex they lovingly crafted elsewhere
doesn't work (not that the various java, Perl, etc schisms help).

Michael Kay
Saxonica

alternately, you may find that some processors 'bend the rules a
little' eg. I think (I maybe wrong) basex for example may allow
lookbehind/lookahead.

unsure about the original reason to restrict regex, as it seems to
just confuse people when a regex they lovingly crafted elsewhere
doesn't work (not that the various java, Perl, etc schisms help).

I am all for upgrading regex expressions, feels like very low hanging
fruit to me.

J


On Thu, Feb 28, 2013 at 1:20 AM, Manuel Souto Pico
<m.soutopico@xxxxxxxxx> wrote:
> Hi there,
>
> I've been using XSLT/XPath for some time to find patterns in
> (XML-based) XLIFF files, but now I'm going to need more complex
> regexps (e.g. positive/negative lookaround/lookbehind/lookahead, aka
> zero-width assertions, or non-capturing groups) and I see that they
> are not supported.
>
> My question is whether there are plans to support these advanced
> features in the future. Does anyone know?
>
> I know .NET or Perl regular expressions support that, but I would
> rather stick to XSLT if I can. It makes my life much simpler.
>
> Thanks in advance.
>
> Cheers,
> Manuel Souto Pico

Thank you, Liam.

I will have a look at the W3C Bugzilla and will try to add a feature
request. It's good that it's so relatively easy to have features
included in the language.

The reason why this is needed is to be able to find all kinds patterns
in XML files, as a kind of linguistic quality control. Lack of
lookaround assertions is a serious limitation when using XSLT to
generate reports based on the input XML document.

Cheers,

Manuel Souto Pico
Linguist 7 Translation technologist
http://www.msoutopico.es
es.linkedin.com/in/msoutopico


On 28 February 2013 03:24, Liam R E Quin <liam@xxxxxx> wrote:
>
> On Thu, 2013-02-28 at 00:20 +0000, Manuel Souto Pico wrote:
> > Hi there,
> >
> > I've been using XSLT/XPath for some time to find patterns in
> > (XML-based) XLIFF files, but now I'm going to need more complex
> > regexps (e.g. positive/negative lookaround/lookbehind/lookahead, aka
> > zero-width assertions, or non-capturing groups) and I see that they
> > are not supported.
>
> The best way to ask for such features is to enter them into the W3C
> Bugzilla instance for the Path & XQuery Functions and Operators
> specification, together with a use case for why they are needed.
>
> Note that the 3.0 "Candidate Recommendation" draft does have
> non-capturing (?....) groups.  I don't think we added the zero-width
> assertions, possibly because no-one has asked for them.
>
> See http://www.w3.org/TR/xpath-functions-30/ for the latest version of
> Functions and Operators, and the Status section at the start has
> instructions for submitting comments.
>
> I am not sure that we can add such features for 3.0, because the
> metaphorical train is already pulling out of the metaphorical station
> with a full head of metaphorical steam, but if we've missed it there's
> likely to be an XPath 3.1 right behind it, as soon as the platform's
> clear. Metaphorically speaking.
>
> Liam
>
> --
> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
> Pictures from old books: http://fromoldbooks.org/
> Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

  Some of
these CDATA sections have CDATA sections in them.

 <p>Creating Inted.</p><p>You can also ptions.</p>
<h1>Generating</h1><p><ac:link><ri:page ri:content-title="Types of
Widgets" /><ac:plain-text-link-body>Infographic widgets
</ac:plain-text-link-body></ac:link> are ways.</p>

On Thu, 2013-02-28 at 19:50 -0800, John Laurence Poole wrote:
[...]

> What I would like to have is the ability to get
> the name of a template in instances where the
> template is invoked via the match mechanism:
> xsl:apply-templates.
[...]

> Maybe I'm barking up the wrong tree and the matching mechanism is not
> what I'm imagining?

You probably want the saxon mailing list... but this is a fairly unusual
question. For a template or XSLT function you could process the
stylesheet with XSLT to provide the information in a variable.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

On Fri, 2013-03-01 at 03:11 +0000, Manuel Souto Pico wrote:
> Thank you, Liam.
> 
> I will have a look at the W3C Bugzilla and will try to add a feature
> request.

Cool. The worst that can happen is someone can tell you it' already
there, or that we won't do it in this version :)  Your "bug"/request
should be filed against XPath and XQuery Functions and Operators in this
case, because that's where replace() and matches() are defined.

>  It's good that it's so relatively easy to have features
> included in the language.
W3C Process requires Working Groups to consider all public comments.

Of course, they might turn round and say "no" :-)


> The reason why this is needed is to be able to find all kinds patterns
> in XML files, as a kind of linguistic quality control. Lack of
> lookaround assertions is a serious limitation when using XSLT to
> generate reports based on the input XML document.

Actually I 100% agree, I use them in other languages.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

I'm resurrecting an old 2009 topic regarding
getting the name of a template.

I followed Michael's suggestion below and have
successfully written an extension function that
produces the names of the template in instances
where the template is invoke through the
xsl:call-template mechanism.

I'd be happy to provide a how-to on how I accomplished this along with
demonstration files if someone would like them; I suspect this is a
very esoteric area and there would not be any takers on my offer.

What I would like to have is the ability to get
the name of a template in instances where the
template is invoked via the match mechanism:
xsl:apply-templates.  This would be for instances where
the template has a name attribute, e.g. name="template_ABC".  I tried
invoking my function similar to that below in a match situation and
null was returned despite the fact that the template that matched had
a name attribute.

Any suggestions on how to approach this?  I'm new to studying the
internals of Saxon, but believe there must be some place where
information about the templates is stored to be accessed by the parser
for the match facility and that extending the properties of the
storage model to include a name attribute in instances where a
template does have a name attribute would be the way toapproach this.
Maybe I'm barking up the wrong tree and the matching mechanism is not
what I'm imagining?

Thanks,

John Poole


here's the message I'm following up on:

On 2009-02-11 11:57:49  Michael Kay posted to this list:

If you're prepared to grovel around the depths of Saxon internals, you can
write an extension function


public static String getTemplateName(net.sf.saxon.expr XPathContext context)
{
     try {
        return context.getOrigin().getObjectName().getDisplayName();
     } catch (Exception err) {
        return null;
     }
}

and call it without any arguments as xx:getTemplateName(). Not tested. It
will only give the template name if it was invoked using call-template.
Should probably work for function calls as well.

Michael Kay
http://www.saxonica.com/

On Thu, 2013-02-28 at 15:47 -0800, dvint@xxxxxxxxx wrote:
> [...] Some of
> these CDATA sections have CDATA sections in them.
Are you sure about that?...

CDATA sections don't nest, which is why the "inner" one is terminated
with "]] >" instead of"]]>".

What you actually have is, to use technical parlance, a mess....

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/28/2013 06:47 PM, dvint@xxxxxxxxx wrote:
> I have an XML file that is an export from a Wiki site. The
> management information for the wiki is in clear XML, bu tthe
> information contained in the pages (actual content) has been
> wrapped in CDATA sections. Some of these CDATA sections have CDATA
> sections in them. I need to extract the content and create
> individual files for each of the pages.

You will need to preprocess the content, I think.

There is no such thing as a nested CDATA section (just like there is
no such thing as a nested comment).  The first ]]> ends the currently
open CDATA section, period.  It looks like the generating software
gets around this, if your pasted example, is accurate, by inserting a
space; the nested sections end in ]] >
(bracket-bracket-space-greaterthan).

You could handle this in XSLT, but I think thatbs doing it the hard way.

~Chris
- --
Chris Maden, text nerd  <URL: http://crism.maden.org/ >
  FIVE TONS OF FLAX
GnuPG fingerprint: DB08 CF6C 2583 7F55 3BE9  A210 4A51 DBAC 5C5C 3D5E
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iQEcBAEBAgAGBQJRL+92AAoJEEpR26xcXD1exLsIAIzpRmvlh+d7+GT6S2UPmrQD
ts1QKkFi+Dkc2abFum/0esl78ryb5S0fjuZPd0S2qFA82pIphvcKlsk9mcpr/g7x
gCrXUm7d7VJDOF5Wr6ccQIdFlvkyoKqNVsH2l3zKU6BPVktx1j2IMbXi5oIPYHXw
1kObMQ89eEx7iW1jc7/xVKuRyKycwltMeNd4DEMoQnYpg1y+5UgukDESMWXstbY4
u7kTfDeufpU9mKG7VdQbKYzBdn++v5hKw4LiV+tNfWcMTvHxUrjAnZ2xdQyG2tsa
tYqSWhQBDNpz0/W6ESmJdFdHMA41yTsof1mz4F8833qxnwDbr4jOVq6BaiTltpg=
=s6no
-----END PGP SIGNATURE-----

CDATA sections don't nest, which is why the "inner" one is terminated
with "]] >" instead of"]]>".

What you actually have is, to use technical parlance, a mess....

Liam

..dan
---------------------------------------------------------------------------
Danny Vint

Panoramic Photography
http://www.dvint.com

I have an XML file that is an export from a Wiki site. The management
information for the wiki is in clear XML, bu tthe information contained in
the pages (actual content) has been wrapped in CDATA sections. Some of
these CDATA sections have CDATA sections in them. I need to extract the
content and create individual files for each of the pages.

So my first hurdle is unwrapping all these CDATA sections. I was handling
the first one with a simple

<xsl:result-document method="xml" href="{element/id}.html">
    <html xmlns:ac="foo" xmlns:ri="bar">
            <xsl:value-of  disable-output-escaping="yes"
select="normalize-space(key('objects',
id)/property[@name='body'])"/>
    </html>
</xsl:result-document>

Is there some trick to deal with the nesting that I might try? So far it
looks like I have about 3 levels to deal with. Content I'm processing
looks like this:
<hibernate-generic datetime="2012-12-30 17:00:12">
<object class="BodyContent" package="com.atlassian.confluence.core">
		<id name="id">37749131</id>
		<property name="body">
			<![CDATA[<p>Creating Inted.</p><p>You can also ptions.</p>
<h1>Generating</h1><p><ac:link><ri:page ri:content-title="Types of
Widgets" /><ac:plain-text-link-body><![CDATA[Infographic widgets]] >
</ac:plain-text-link-body></ac:link> are ways.</p>]]>
		</property>
		<property name="content" class="Page"
package="com.atlassian.confluence.pages">
			<id name="id">37716459</id>
		</property>
		<property name="bodyType">2</property>
	</object>
</hibernate-generic>

This is my typical situation where there are little CDATA sections for the
filenames, but I have seen other situations where large sections of
content have been wrapped this way as well.

I can brute force this and process my output file several times to finally
cleanup all the CDATA sections, but I would like to be more elegant.

Also I will have a need to de-reference these <id> elements within the
original context, so even my current simple approach is going to cause
problems. This current approach has extracted the content so I can take a
look at it easily, but ultimately I really would like to submit that first
CDATA section in the <property> element for additional processing. For
instance those <ac:link> elements need to be converted to a different
linking structure like the more typical <a href=""> form.

..dan

Something like

<xsl:for-each select="1 to string-length($alphabet)">
  <xsl:call-template name="keyboard">
    <xsl:with-param name="letter" select="substring($alphabet, ., 1)"/>

perhaps?

Or if you want groups of six, something along the lines of

<xsl:for-each select="0 to ceiling(string-length($alphabet) div 6)">
  <xsl:call-template name="keyboard">
    <xsl:with-param name="letter" select="substring($alphabet, .+1, 6)"/>

You'll have to sort out the boundary conditions for yourself.

Michael Kay
Saxonica

On 28/02/2013 05:07, Mark Wilson wrote:

Hello,
I want to write a template that would, for each letter in some specified alphabet, call the following template to create a cell for an HTML table in the output document. Is there a way to set up something that would select each letter from an alphabet stored in a stylesheet parameter and call the 'keyboard' template? Since various alphabets have differing lengths and content, I was thinking of perhaps a string as the parameter. It would be very helpful to be able to trigger the template in groups of six to accommodate the <tr> elements.

I looked at XPath 'for' but could not see a means of triggering the 'keyboard' template.

Thanks,
Mark

<xsl:template name="keyboard">
<xsl:param name="letter"/>
<xsl:param name="this-page-name"/>
<xsl:choose>
<xsl:when test="not($this-page-name eq $letter)">
<xsl:variable name="file-name" select="concat(lower-case($letter),'.htm')"/>
<td>
<a href="{$file-name}">
<xsl:value-of select="$letter"/>
</a>
</td>
</xsl:when>
<xsl:otherwise>
<td class="current">
<xsl:value-of select="$letter"/>
</td>
</xsl:otherwise>
</xsl:choose>
</xsl:template>

--
Mark Wilson
Knihtisk Publishing

<xsl:for-each select="1 to string-length($alphabet)">
  <xsl:call-template name="keyboard">
    <xsl:with-param name="letter" select="substring($alphabet, ., 1)"/>

<xsl:for-each select="0 to ceiling(string-length($alphabet) div 6)">
  <xsl:call-template name="keyboard">
    <xsl:with-param name="letter" select="substring($alphabet, .+1, 6)"/>

Michael Kay
Saxonica

Hello,
I want to write a template that would, for each letter in some specified alphabet, call the following template to create a cell for an HTML table in the output document. Is there a way to set up something that would select each letter from an alphabet stored in a stylesheet parameter and call the 'keyboard' template? Since various alphabets have differing lengths and content, I was thinking of perhaps a string as the parameter. It would be very helpful to be able to trigger the template in groups of six to accommodate the <tr> elements.

I looked at XPath 'for' but could not see a means of triggering the 'keyboard' template.

Thanks,
Mark

<xsl:template name="keyboard">
<xsl:param name="letter"/>
<xsl:param name="this-page-name"/>
<xsl:choose>
<xsl:when test="not($this-page-name eq $letter)">
<xsl:variable name="file-name" select="concat(lower-case($letter),'.htm')"/>
<td>
<a href="{$file-name}">
<xsl:value-of select="$letter"/>
</a>
</td>
</xsl:when>
<xsl:otherwise>
<td class="current">
<xsl:value-of select="$letter"/>
</td>
</xsl:otherwise>
</xsl:choose>
</xsl:template>

Hi there,

I've been using XSLT/XPath for some time to find patterns in
(XML-based) XLIFF files, but now I'm going to need more complex
regexps (e.g. positive/negative lookaround/lookbehind/lookahead, aka
zero-width assertions, or non-capturing groups) and I see that they
are not supported.

My question is whether there are plans to support these advanced
features in the future. Does anyone know?

I know .NET or Perl regular expressions support that, but I would
rather stick to XSLT if I can. It makes my life much simpler.

Thanks in advance.

Cheers,
Manuel Souto Pico