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: Re: [dss-x] TAML


Hi Juan Carlos,
> I have been looking at the XML file circulated by Andreas. Actually I
> find it very interesting. For your information, I comment that ETSI
> produced TS  119 134 Part 5: "Conformance Testing for XAdES Baseline
> Profile".
>
> This TS collects what intends to be a complete test suite for testing
> conformity of XAdES signatures against the XAdES Baseline Profile,
> specified in ETSI TS 103 171.
>
> The test suite is formed by a set of test assertions, whose formats
> were inspired in TAML. However, they are not defined in XML format.
> Instead they are defined in natural language. The predicates, in
> consequence contain rules expressed in natural language.
>
> One of the reasons for selecting the natural language is that it is
> the intention of ESI to produce similar documents for testing
> compliance against CAdES and PAdES formats, where XML technology is
> not used....
>
> For completing a bit the picture. Within the context of STF-428, in
> addition to this TS, it was also produced a tool for testing
> conformity of XAdES against XAdES Baseline Profile, implementing the
> test suite specified in the document refenced. Because of the plans
> for testing also CAdES, PAdES and ASiC formats, this tool was
> completelly developed in Java, and includes a generic framework that
> should be easily extended to also cover the aforementioned formats. As
> you can see the problem, including different languages to XML, is
> wider than our DSS protocol...
>
> Having said that, I must say that the inclusion of the XML for
> building test assertions constitutes a great approach, despite the
> deep knowledge of XPath and XSLT its building seems to require.
>
> If any experienced person in TAML would like to raise comments that
> could help to improve this, I am sure that they would be greatly
> appreciated by ETSI.
>
I wouldn't call myself an experienced person in TAML (not yet). But I
did a lot of stuff with XML and XSL/XPath. My usual solution to any
multi-format problems is XML ! I prefer to convert any incoming stuff
that somehow builds a tree-like structure (like Java classes, EDIFACT,
ASN.1, PDF, .. ) into an XML tree and apply my usual tool set to this
document. Transformations of any input to any output can be done easily.
And TAML validation is nothing more the applying a special type of
transformation.

Yes, you need to get used to XML/XSL/XPath triple but dtmo it pays off!
My approach for the *AdES-problem would be:

- Define the assertions in TAML
- Transform CAdES and PAdES to an appropriate XML presentation
- Apply the TAML assertions

This way I could avoid defining another validation language and keep the
implementation effort and complexity for the validator as low as possible.

Greetings,

Andreas

-- 
Andreas Kühne 
phone: +49 177 293 24 97 
mailto: kuehne@trustable.de

Trustable Ltd. Niederlassung Deutschland Ströverstr. 18 - 59427 Unna Amtsgericht Hamm HRB 5868

Directors Andreas Kühne, Heiko Veit

Company UK Company No: 5218868 Registered in England and Wales 



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