Project

Profile

Help

Support #5496

closed

Explicit document versus implicit document

Added by Jiri Dolejsi almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Low
Assignee:
Category:
-
Sprint/Milestone:
-
Start date:
2022-05-18
Due date:
% Done:

0%

Estimated time:
Legacy ID:
Applies to branch:
11
Fix Committed on Branch:
Fixed in Maintenance Release:
Platforms:
.NET

Description

in this case validation is preserved:
<xsl:mode on-no-match="shallow-copy"/>
 <xsl:template match="/">
    <xsl:apply-templates select="/newsItem"/>
</xsl:template>

in this case validation is striped:
<xsl:mode on-no-match="shallow-copy"/>
 <xsl:template match="/">
    <xsl:document>
       <xsl:apply-templates select="/newsItem"/>
    </xsl:document>
</xsl:template>

In our application we evaluate xpath on transformed document and in the first case it returned error: The supplied node has been schema-validated, but the XPath expression was compiled without schema-awareness but in second case it return success.

Actions #1

Updated by Michael Kay almost 2 years ago

I'm struggling a bit finding my way around the spec on this one - it's been a while.

The default value of xsl:document/@validation is defined in §25.4:

The [xsl:]type and [xsl:]validation attributes are mutually exclusive. Both are optional, but if one is present then the other must be omitted. If both attributes are omitted, the effect is the same as specifying the validation attribute with the value specified in the [xsl:]default-validation attribute of the innermost containing element having such an attribute; if this is not specified, the effect is the same as specifying validation="strip".

So in your case it's validation="strip" which means the constructed (copied) document is untyped, so a non-schema-aware XPath expression should work.

For the implicit nodes created using built-in templates with a shallow-copy mode, the rules are given in §6.7.3, and are equivalent to using <xsl:copy validation="preserve"> which preserves the type annotations on the input document.

So I think that you are correct to observe that the two cases are different, and Saxon is behaving correctly according to the spec.

Is this causing you a problem?

Actions #2

Updated by Jiri Dolejsi almost 2 years ago

No, it is not problem for us. I am not sure, if the behavior was the same in IKVM Saxon, but I have not tried. Also it seems to me, that input document to transformation (in our application) is not validated. Is it possible to find, if XdmNode instance is validated or not in C# ?

Actions #3

Updated by Michael Kay almost 2 years ago

I can't see how you would get the message "The supplied node has been schema-validated" unless that's actually the case.

The best way to discover whether a node is typed is probably to test xdmNode.Implementation.getSchemaType().getName() which (for an element node) will return "untyped" if not validated.

Actions #4

Updated by Michael Kay almost 2 years ago

For the next release, I've added XdmNode.TypeAnnotationName to get this directly.

Actions #5

Updated by Jiri Dolejsi almost 2 years ago

I tested type of document (doc.Implementation.getSchemaType().getName()) In the first case(without xsl:document): type of input doc(before transformation) = untyped, type of output doc(after transformation) = anyType in the second case(with xsl:document): type of input dod = untyped, type of outp doc = untyped

In our application we store input document in the Postgres database as jsonb type and we dynamicaly reconstruct xml when it is needed. So I can not send you sample input xml doc.

Actions #6

Updated by Martin Honnen almost 2 years ago

Can you share the exact C# code you use to read the input, compile and run the transformation, then compile and run the XPath evaluation on the transformation result?

Actions #7

Updated by Jiri Dolejsi almost 2 years ago

It is scattered in our entire project and I now do not have time to gather all pieces together. But if you are interested, I can slowly gather it. If not, we can close this issue.

Actions #8

Updated by Michael Kay almost 2 years ago

  • Status changed from New to Closed
  • Assignee set to Michael Kay

Closing this as the original question has been answered. Please feel free to reopen if there is fresh information.

Please register to edit this issue

Also available in: Atom PDF