Updated Widget Signature Editors draft
I have updated the Widgets Signature editors draft [1] as follows: 1. Restructured to move definitions section before compliance, merge user agent section into compliance, and provide syntax, processing rules and algorithms sections to mirror XML Signature document structure and separate concerns. 2. Cleaned up definitions, removing unused definitions, rewording and adding needed definitions. Fixed all definition links in document. 3. Added Signature Properties text (as proposed earlier [2]) in section 6.1, with some draft URIs for place holders. 4. Added text for Widget Signature Validation (proposed in [2]) with some modifications 5. Attempted to clean up the RFC 2119 language in section 3 and rest, to use upper case and removed non 2119 language highlighting - to resolve Jere's concern [3] and follow common practice here. 6. Revised generation processing rules to rely on XML Signature, not be algorithmic, and to include properties 7. Added RFC 5280 and Signature Properties references 8. Revised introduction (remove duplicate file name definition), General wording cleanup throughout. Work remains on Certificate, CRL and OCSP profiling, and decisions related to algorithms. regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/ [2] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0042.html [3] http://lists.w3.org/Archives/Public/public-webapps/2009JanMar/0040.html
Re: Copyright license for ElementTraversal Java interface
Hi, Cameron- My opinion is that the editor of the Element Traversal spec simply didn't know what he was doing (no offense). I would suggest that a separate file be made with the appropriate Java interface file, with the appropriate license, and that it be linked from an errata (and later a second edition). Would this work for you, and for the rest of the WebApps WG? Regards- -Doug Cameron McCormack wrote (on 1/11/09 11:04 PM): Hello WG. A question[1] just came up within the ASF about the license under which the ElementTraversal Java interface is made. Unlike some other W3C specifications, where Java interface files are made available as separate files (perhaps within a ZIP file) with a header at the top that states that the file is licensed under the W3C Software License[2], the Element Traversal specification includes the Java interface inline. The specification itself is licensed under the W3C Document License[3], which likely isn’t suitable for inclusion in ASF software distributions. Some time ago, I added the Java interface to the Batik project’s repository[4]. The main contents of that file do not exactly match the text that is in the specification; the formatting is different. I did however add the Apache License header to the top of that file, as is done with other non-external source code. Given that the contents of the file don’t exactly match the text in the spec (but is quite similar), and could reasonably have been generated from the IDL, I’m not sure if including that header was the correct course of action. So my questions are: 1. Should I replace the ElementTraversal.java file in the Batik repository with one that is identical to the text in the Element Traversal spec, but with a W3C license header at the top, and if so, which one? 2. Should the W3C be explicitly licensing the ElementTraversal.java file under the W3C Software License? Thanks, Cameron [1] http://markmail.org/message/lgqmiixh4l3bdugv [2] http://www.w3.org/Consortium/Legal/2002/copyright-software-20021231 [3] http://www.w3.org/Consortium/Legal/2002/copyright-documents-20021231 [4] http://svn.apache.org/repos/asf/xmlgraphics/batik/trunk/sources/org/w3c/dom/ElementTraversal.java
[ElementTraversal]: Feature string for DOMImplementation.hasFeature(feature, version)?
Hi WG, The DOM Core specification and other DOM modules define feature strings [1] which applications can query to check whether or not a specific DOM module is supported by a DOMImplementation. For example, DOM Level 2 Traversal and Range [2] says: A DOM application may use the hasFeature(feature, version) method of the DOMImplementation interface with parameter values Traversal and 2.0 (respectively) to determine whether or not this module is supported by the implementation. These feature strings are also useful for selecting a DOMImplementation which supports a specific set of features through the methods provided by DOMImplementationRegistry [3]. After reading the spec it doesn't seem like Element Traversal has such a string defined for it, so applications would have no standard way for selecting a DOMImplementation which supports Element Traversal or determining whether the DOMImplementation instance they already have supports it. Is there a reason a feature string was omitted from the spec? An oversight, perhaps? Can this be added to the errata? Thanks. [1] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#DOMFeatures [2] http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/traversal.html#Traversal-overview [3] http://www.w3.org/TR/2004/REC-DOM-Level-3-Core-20040407/core.html#Bootstrap Michael Glavassevich XML Parser Development IBM Toronto Lab E-mail: mrgla...@ca.ibm.com E-mail: mrgla...@apache.org
