[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] Connected attribute rules in schema?


Subject: Re: [xsl] Connected attribute rules in schema?
From: "Trevor Nicholls trevor@xxxxxxxxxxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Mon, 18 Aug 2014 13:53:20 -0000

I am using XSD 1.0.

The XML documents described by this schema are maintained by several tools
which respect the schema (1.0) constraints: Framemaker, XMLSpy and Xopus. I
can detect documents that have set the private attribute without an
explanatory note by running them through a validation stylesheet that tests
constraints that are not specified in the schema, but I would rather have
the editing tools enforce the constraint upon the authors in real time. I
had a quick look at the schematron website, but I can't see how I would
incorporate it into our application.

If it's impossible in XSD 1.0 that's OK, I'll accept the limitations and
work around them.

Thanks for your suggestion though.

cheers
T

-----Original Message-----
From: Michael Schdfer michael.schaefer@xxxxxxxxxxx
[mailto:xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, 19 August 2014 1:35 a.m.
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] Connected attribute rules in schema?

What version of XML Schema do you use? AFAIK, XSD 1.1 offers some support in
this direction, but I've stuck with 1.0 at the moment and don't know if they
will meet your requirements.

However, Schematron should do the trick for you
(http://www.schematron.com/). It's am XML-based language for making
assertions about patterns in documents such as the one you've described.

Schematron rules are compiled into XSLT stylesheets. They can be define in a
standalone document as well as included into an XSD schema (requires a
validating parser that supports this). Of course, you can generate an run
the stylesheets independently from an XSD validation. There are even ways of
customizing the validation reports generated by Schematron. This gives you a
lot of flexibility.

Regards,

Michael

Am 18.08.2014 14:59, schrieb Trevor Nicholls trevor@xxxxxxxxxxxxxxxxxx:
> An XML element has numerous potential attributes, most of them optional.
> In a couple of cases, an attribute needs to be mandatory if another
> attribute has a particular value. Is there a way of defining this in
> the document schema?
>
> For example the following might define a code fragment, consisting of
> text with embedded <nl> elements. The fragment can be highlighted or
> not (highlight=Y or highlight=N), and it can be flagged as private
> or not (private=Y or private=N). There is an optional note
> attribute, which can among other things provide a reason for the
> element to remain private.
>
> <xs:simpleType name="boolean">
>
>    <xs:restriction base="xs:string">
>
>      <xs:enumeration value="Y"/>
>
>     <xs:enumeration value="N"/>
>
>    </xs:restriction>
>
> </xs:simpleType>
>
> <xs:element name="nl">
>
>    <xs:complexType/>
>
> </xs:element>
>
> <xs:complexType name="fragment" mixed="true">
>
>    <xs:choice minOccurs="0" maxOccurs="unbounded">
>
>      <xs:element ref="nl"/>
>
>   </xs:choice>
>
>    <xs:attribute name="highlight" type="boolean"/>
>
>    <xs:attribute name="private" type="boolean"/>
>
>    <xs:attribute name="note"/>
>
> </xs:complexType>
>
> Is there any way to indicate in the schema that the note attribute
> is mandatory IF private=Y?
>
> Coalescing the two attributes into one (e.g. privatereason) and
> using a value or no value as equivalent to a Boolean test is not
> feasible because there are legitimate cases for a note when the
> element is not private.
>
> Thanks for any ideas
>
> T
>
> XSL-List info and archive <http://www.mulberrytech.com/xsl/xsl-list>
> EasyUnsubscribe <-list/696613>
> (by email <>)

--
___________________________________________

    Michael Schdfer

    C302 IT-Kompetenzzentrum Datenerhebung
    und Aufbereitung

    Telefon +49 (0)611.753652

    michael.schaefer@xxxxxxxxxxx
    www.destatis.de

    DESTATIS
    wissen.nutzen. | Statistisches Bundesamt


Current Thread