xsl-list
[Top] [All Lists]

Re: [xsl] Connected attribute rules in schema?

2014-08-18 08:53:32
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 Schäfer michael(_dot_)schaefer(_at_)destatis(_dot_)de
[mailto:xsl-list-service(_at_)lists(_dot_)mulberrytech(_dot_)com] 
Sent: Tuesday, 19 August 2014 1:35 a.m.
To: xsl-list(_at_)lists(_dot_)mulberrytech(_dot_)com
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(_at_)castingthevoid(_dot_)com:
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 Schäfer

    C302 IT-Kompetenzzentrum Datenerhebung
    und Aufbereitung

    Telefon +49 (0)611.753652

    michael(_dot_)schaefer(_at_)destatis(_dot_)de
    www.destatis.de

    DESTATIS
    wissen.nutzen. | Statistisches Bundesamt
--~----------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
EasyUnsubscribe: http://lists.mulberrytech.com/unsub/xsl-list/1167547
or by email: xsl-list-unsub(_at_)lists(_dot_)mulberrytech(_dot_)com
--~--

<Prev in Thread] Current Thread [Next in Thread>