[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss-x] Visual Document Signatures
Dear Uri, > "Uri Resnitzky" <Uri@arx.com> wrote on 20070805T194629+0200: > ... > Please find attached ARX's contribution towards a profile for visual > document signatures. > The attached document is by no means complete or fully specified - it > should be viewed as a basis for further discussions. > Please start by reading section 3 which describes some of the key > aspects of the proposed profile as well as motivations and use cases. I consider this a very good start for us into the analysis of what should be included in such a profile and what should be better separated into different profiles. Some adhoc feedback (probably a bit superficial) from me: <document date='20070805' id='oasis-dss-profiles-visual-document-signatures-wd-01.pdf'> <location> <input>4.1.1.5 Optional Input <ReturnPDFTailOnly></input> <feedback date='20070806' origin='sdrees' id='DomainSpecific'>If the Profile targets at PDF, ODF and OOXML, it MAY be a better choice to embed client format specific information elements into an extra (optional) container. In a then second level, the profile may have elements bearing specialized names of importance to only one specific processing hierarchie/chain. This may result in parsing efficiency, where the file-format-specific parsers are only used inside "the processing of" the "Here_MAY_be_file_format_specific_settings_inside"-Container </feedback> </location> <location> <input>4.1.1.6 Optional Input <GraphicImageName></input> <feedback date='20070806' origin='sdrees' id='NameOrID_01'> I expect some discussions here, clarifying two problems (as far as I can see) 1. Is it a Name or is it an ID (unique name [plus conventions]) and if it is a kind of ID (I assume this from context): who has enough information to know and/or select from such a set of IDs. This is not necessarily the task of the profile, but it may render using the profile problematic if not taking it into account. I picture this as the usual problem, when many end-users have to choose among signatures, addresses and the like while using applications, that try to display "stuff partially but nicely" ... </feedback> </location> <location> <input>4.1.1.7 Optional Input <SignatureFieldName></input> <feedback date='20070806' origin='sdrees' id='NameOrID_02'> This is only listed separately for taking into account, that a "funny picture" as someone put this may be of complete different meaning as compared to a CMS or XML Signature. Besides this, please see also feedback with regard to "4.1.1.6 Optional Input <GraphicImageName>". </feedback> </location> <location> <input>4.1.1.9 Optional Input <GMTOffset></input> <feedback date='20070806' origin='sdrees' id='ServerTimeOffsetUTC'> At a minimum I would suggest the nowadays correct UTC (Universal Time Coordinated) in exchange with GMT (Greenwich Mean Time). What I would personally tend to name it, would be more along the lines of <ServerTimeUTCOffset>, to emphasize the intended impact in the processing. </feedback> </location> </document> ALl the best, Stefan Drees.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]