Hi Dave,
[...]
> and any other ns'd element is rejected (by the schema)?
> Is this the 'default rule' clas of action? 6.4.12?
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.
[...]
> Yes, haven't got that far yet, but I struggled allowing *any* start
pattern
> from xslt, when the schema only allowed stylesheet. Is that what triggers
> are all about?
Triggers allow you to have a better granularity on the sections, they
allow you to have different sections even if they have the same
namespace and an element in the first section is the parent of the start
element of the other section. Thus it is possible to apply different set
of rules (modes) for elements that otherwise would have been part of the
same section.
Note that triggers scope is global, so you cannot have different set of
triggers for different modes.
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.
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. 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.
Best Regards,
George
---------------------------------------------------------------------
George Cristian Bina
<oXygen/> XML Editor, Schema Editor and XSLT Editor/Debugger
http://www.oxygenxml.com
Dave Pawson wrote:
> Hi George.
>
> On 23/02/07, George Cristian Bina <george@oxygenxml.com> wrote:
>
>> Each rule matches/defines sections in the document and it contains what
>> actions should be applied on those sections. The actions have as a
>> property the mode to be used further, that mode can be specified with
>> the useMode attribute or with the mode element inside the action. If no
>> mode is specified with any of the above then current mode is used
>> further.
>
> and any other ns'd element is rejected (by the schema)?
> Is this the 'default rule' clas of action? 6.4.12?
>
>> Note that NVDL adds triggers that can define different sections inside
>> the same namespace. For instance if we define table, tr and td from the
>> XHTML namespace as the list of trigger elements then if we have an XHTML
>> document then the tables and their structure defined with tr and td
>> elements will be in a different section.
>
> Yes, haven't got that far yet, but I struggled allowing *any* start pattern
> from xslt, when the schema only allowed stylesheet. Is that what triggers
> are all about?
>
> 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)Received on Fri Feb 23 13:59:27 2007
This archive was generated by hypermail 2.1.8 : Fri Feb 23 2007 - 15:13:11 UTC