[dsdl-comment] Re: modes Scope.

Hi Dave,

[...]
>> Note that if you can obtain a valid XSLT by removing elements from other
>> namespaces and attributes from your document then you can use NVDL to
>> build this XML fragment and validate it with your schema.
> Sorry I don't understand that sentance.

If you have something like

<sample:test xmlns:sample="sample">
  <sample:a>
   <xsl:stylesheet xmlns:xsl="">
    <sample:b>
      <xsl:template match="/">
      </xsl:template/>
    </sample:b>
   </xsl:stylesheet>
  </sample:a>
</sample:test>

Then you can obtain an XSLT document by removing all the elements from
the sample namespace
<xsl:stylesheet xmlns:xsl="">
  <xsl:template match="/">
  </xsl:template/>
</xsl:stylesheet>
In this case it should be possible to write an NVDL script that gets all
the XSLT content by attaching all XSLT sections each up to the previous
one and that validates the whole XSLT fragment against the XSLT schema.

[...]
>> For instance you can have a
>> schema for XSLT that defines all XSLT elements, each allowing any XSLT
>> element inside.
> I *think* that would have been too loose for what I wanted?

Probably, it depends on what you want :). But from a previous email from
you (a private email I think) I remember that you may have as input
xsl:choose without an xsl:when or xsl:otherwise - so it is more to
change in the XSLT schema than only to add more start elements.
Recalling that discussion I think the solution I suggested then was to
make all the required content optional.

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

Dave Pawson wrote:
> On 23/02/07, George Cristian Bina <george@oxygenxml.com> wrote:
>
>> If there is no specific rule matching that namespace and the mode does
>> not contain an anyNamespace rule matching elements then the default
>> anyNamespace rule is applied, that means a reject action is applied on
>> those sections.
>
> Glad I've got something right! Thanks.
>
>> Note that triggers scope is global, so you cannot have different set of
>> triggers for different modes.
> Noted.
>
>>
>> The document is split into elements and attribute sections, each section
>> containing only components in a single namespace. Then sections may be
>> combined using actions like attach, unwrap for instance with other
>> sections. The validate action is applied on such a set of sections that
>> in the end represents an XML fragment from your initial document. Now,
>> if you have a schema that specifies only stylesheet and transform (from
>> the XSLT namespace) as global/start elements then that schema will not
>> validate a fragment that starts with a different element, it will accept
>> only fragments that start with stylesheet or transform.
> Yes, the validation showed me that.
> Hence I modified the sub-schema (terminology?) to give me n start elements
> in a choice block. That allowed me (for instance) to validate starting
> at xsl:choose.
>
>
>> Note that if you can obtain a valid XSLT by removing elements from other
>> namespaces and attributes from your document then you can use NVDL to
>> build this XML fragment and validate it with your schema.
> Sorry I don't understand that sentance.
>
> Otherwise the
>> semantics of your schema and the semantics of the fragments you have in
>> your compound document do not match and you should use a different
>> schema that matches your document semantics. For instance you can have a
>> schema for XSLT that defines all XSLT elements, each allowing any XSLT
>> element inside.
> I *think* that would have been too loose for what I wanted?
>
>
> My eventual solution was to import the 'real' xslt schema into a schema
> with
> a 'start/@combine' which listed all the elements I needed as the root of my
> 'mini-schema' for nvdl validation. It seemed wrong somehow.
>
> More reading called for George.
> Thanks for the explanation.
>
> regards
>
>

--
DSDL comments
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-comment-request@dsdl.org
(mailto:dsdl-comment-request@dsdl.org?Subject=unsubscribe)