OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Response to Question 2. Re: [dss-x] Feedback on the use of the DSS visible signature profile

Dear Ernst Jan,

with regard to your second observation (and question raised) I offer the following motivation/explanation:

The core offers:
	<xs:element name="ServicePolicy" type="xs:anyURI"/>
the profiles author suggested a restricted domain type, not being constrained to xs:anyURI, thus (as I recall the evolution of the profile) the follwoing was suggested for that profile:

<xs:element name="VisibleSignaturePolicy"

<xs:simpleType name="VisibleSignaturePolicyType">
	<xs:restriction base="xs:string">
		<xs:enumeration value="DocumentSubmissionPolicy" />
		<xs:enumeration value="SimpleWorkflowPolicy" />
		<xs:enumeration value="WorkflowPolicy" />
		<xs:enumeration value="GeneralPolicy" />

Allthough formally the four strings given in the aforementioned profile may qualify as relative URIs, I understood the focus in using anyURIs as "to specify the intention that the value fulfills the role of a URI as defined by [RFC 2396], as amended by [RFC 2732]." (from the spec at http://www.w3.org/TR/xmlschema-2/#anyURI)

Maybe this way inside profile (here standalone snippet):
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"; elementFormDefault="qualified">
<xs:simpleType name="VisibleSignaturePolicyType">
        <xs:restriction base="xs:anyURI">
            <xs:enumeration value="DocumentSubmissionPolicy"/>
            <xs:enumeration value="SimpleWorkflowPolicy"/>
            <xs:enumeration value="WorkflowPolicy"/>
            <xs:enumeration value="GeneralPolicy"/>
<xs:element name="ServicePolicy" type="VisibleSignaturePolicyType"></xs:element>

and some sample instance (conforming to that snippet (a_sample.xsd):

<?xml version="1.0" encoding="UTF-8"?>
<ServicePolicy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";


Plus / minus my typing errors :?)

So I think we could have "overwritten" the anyURI in the core "offering" by a more restrictive set of four enumerations (as above) but historically did not choose to do so.

All the best,

Am 14.05.12 15:23, schrieb Ernst Jan van Nigtevecht:
Related to DSS profile visual signatures:

(2) It seems that the ServicePolicy is not yet used. Instead, some
profiles define their own policy elements.

DSS-Core: 2.8.1 Optional Input <ServicePolicy>

DSS-profile-visualsig: Optional Input <VisibleSignaturePolicy>

Question 2:
Why has that been done?

Attachment: smime.p7s
Description: S/MIME Kryptografische Unterschrift

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]