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


Help: OASIS Mailing Lists Help | MarkMail Help

dss-dev message

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

Subject: Re: [dss-dev] Data format guessing of data within Base64Data tag

On 24.04.13 08:04, Juan Carlos Cruellas wrote:
... See below intermixed...
first of all it should be clear, that no direct violation of
conformance is notable.

mmm... I am not sure what you mean by that...and what do you think is
the actual extent of this assertion...does this mean that any
conformance violation is not notable, i.e. does not have big relevance?...

no. As I am a non-native english writer, please excuse. I meant "noticeable" or the like synonym to "observable".

I already stated (cf. in citation below) my remembrance of the motivation as why we did not write "This contains a base64 encoding of data that MUST NOT be XML." inside the <Base64Data> element" but instead only wrote "This contains a base64 encoding of data that are not XML. " (section 2.4.2 description of this attribute).

But, the reason for inventing Base64Data was not, to certify, that the
content is no XML. The motivation was: How can we tunnel/embed
something not being XML inside an xml container for signing purposes?
Just imagine an intermediate version of an xml document neither
wel-formed not valid.
If it is not well formed then I doubt it could be detected as being XML
by any well designed application. I think that any XML parser would
throw an exception which should lead to the application to conclude that
this is not XML....

that may well be, I just pointed to a use case, where dss offers a convenient robust sign slot for "wannabe-XML documents in early editing stages".

Anyway, still I think that the present tense in the sentence that I
highlighted has the value of a mandatory requirement...if we have
different views, then I feel that it could make sense to ammend it in
one sense or the other...however, if we could get more insight of what
other implementers' reading, it would be great...

The former I doubt as outlined above, as no xml is not equivalent to "MUST NOT be xml" and the latter has already been requested :-)

How would you sign this as "your version of thursday, say 1300 CEST :-?

As a server "programmer" I am still curious what might motivate a
service to parse something, the spec sees only as data ... ?
not only data...."no XML data"....

All the best,

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