{10} comments (87 matches)

see: https://pypi.python.org/pypi/tratihubis/

Information about Trac tickets to convert has to be provided in a CSV file. To obtain this CSV file, create a new Trac queries using the SQL statement stored in query_tickets.sql and query_comments.sql.

Ticket Posixtime Author Newvalue
#1 1210879890 prjemian tried HTML but formatting not as simple (to be as elegant) as the wiki
#1 1210879943 prjemian new wiki documentation established. See http://www.smallangles.net/wgwiki/index.php/cansas1d_binding_IgorPro
#2 1205432681 prjemian resolved in changeset [10] Check for all required elements in <IData> Also check for same number of points. Check for optional fields and compare number of points when present. Flag these as errors but do not stop processing. Just continue to next SASdata or SASentry, as it exists.
#3 1205432763 prjemian Jan Ilavsky has agreed to start working on this.
#3 1221223140 prjemian implemented: [http://usaxs.xor.aps.anl.gov/staff/ilavsky/irena.html]
#4 1253307371 prjemian This is implemented in Jan's Irena macro package for IgorPro.
#5 1206035826 prjemian used '''cansas1d/1.0''' instead of '''canSAS1d/1.0''' since that could be a significant typo for some folks
#5 1206202206 prjemian resolved by changeset [21] all examples updated (includes IgorPro support test cases)
#6 1206036630 prjemian Suggest that the change be implemented as: Q; I [; Idev] [; Qdev] [; Qmean] [; ShadowFactor] Qfwhm will be dropped
#6 1206037129 prjemian Andrew Jackson requests: ''Can we have dQv and dQh fields to describe slit smeared data?'' Add these columns, as well: Qh,Qv, with the special rule that: Qdev xor (dQv or dQh) That is, Qdev, dQv, or dQh are optional but Qdev cannot be appear with either of the other two. (That logic should be a bear, er ''challenge'' to implement in XML Schema.) Columns will be: Q; I [; Idev] [ [; Qdev] | [ [; dQv] [; dQh] ] ] [; Qmean] [; ShadowFactor?]
#6 1206246304 prjemian here's how it will be done in the cansas1d.xsd XML schema: (documentation removed) {{{ <xsd:choice> <!-- [ [Qdev] | [[dQv] | [dQh]] ] --> <element name="Qdev" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0"> </element> <xsd:sequence> <element name="dQw" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0"> </element> <element name="dQl" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0"> </element> </xsd:sequence> </xsd:choice> }}}
#6 1206905405 prjemian Slight change of plans after reviewing principles with the persons requesting the change. The desire is to represent the resolution in two dimensions of Bonse-Hart type SAS instrument. The terms '''dQh''' and '''dQv''' refer to horizontal and vertical components. These terms still remain dependent on the orientation of the SAS instrument. (Most Bonse-Hart instruments scan in the horizontal plane with vertical rotation axis. Synchrotron Bonse-Hart USAXS prefer to scan in the vertical plane with horizontal rotation axis due to favorable polarization term.) After review, made the change to the more appropriate terms: '''dQw''' and '''dQl''' '''dQw''': resolution in the Q-scanning direction '''dQl''': resolution in the direction transverse to Q scanning {{{ <xsd:choice> <!-- [ [Qdev] | [[dQw] | [dQl]] ] --> <element name="Qdev" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" /> <xsd:sequence> <element name="dQw" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" /> <element name="dQl" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" /> </xsd:sequence> </xsd:choice> }}}
#7 1206135503 prjemian This was discussed at the 2007 canSAS workshop and partly implemented in the standard, in the SASnote element. It may be possible to implement in other places in the standard using the XML Schema ''any'' element declaration. Use of "any" is discouraged since it is antithetical to the theme of standrdization. In this case, it could be used to identify the popularity or usage of elements which are not declared in the existing canSAS standard. There is also a namespace attribute that might be used to note the declared elements (those in the canSAS standard) and the custom ones. It is suggested that where allowed, the {{{<any namespace="##LOCAL" minOccurs="0" maxOccurs="unbounded" />}}} element be the last within its parent element. That is, all the canSAS elements come first.
#7 1206245918 prjemian Here's how it will be done in the cansas1d.xsd XML Schema {{{ <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="skip" namespace="##other"> <annotation> <documentation> <DT> /cs:SASroot/cs:SASentry/cs:SASsample/ &lt;any&gt; </DT> <DD> [0..inf] Provision at this point for any element to be entered that is not part of the canSAS standard. Use a '''xmlns="some-simple-identification-string"''' to identify that this is a ''foreign element.'' </DD> </documentation> </annotation> </xsd:any> }}}
#7 1206904594 prjemian Provision for foreign elements added in several places by changeset [22]
#8 1209154194 prjemian As we last left this one month ago, we decided to have this substructure: {{{ SAScollimation distance aperture size x y z distance aperture (more of these are allowed) }}} This was made consistent today with changeset [26] For a clearer view, see : http://www.smallangles.net/wgwiki/index.php/cansas1d_SAScollimation Things are clearly defined on this page. The problem is that a few things have been out of synch between the block diagrams, the XML Schema, the definition of terms, the template and other items. == Proposal == Propose a change in the name of the "distance" immediately after SAScollimation. By Steve's message on 2008-03-25, SAScollimation/distance describes the "amount/length of collimation inserted on a reactor SANS instrument." I suggest that we change {{{ SAScollimation/distance }}} to {{{ SAScollimation/length }}} and that will make this distinction very clear. That is to say: {{{ SAScollimation length aperture size x y z distance aperture (more of these are allowed) }}}
#8 1209418535 prjemian proposed change implemented as part of [27]
#9 1209418561 prjemian proposed change implemented as part of [27]
#10 1211190674 prjemian Resolved by changeset [39] 1. http://www.smallangles.net/wgwiki/index.php/cansas1d_binding_IgorPro 2. ?Load command? This code does not use it nor vice-versa. 3. repaired one instance with Run = TrimWS( ReplaceString("\\", metadata[j][1], "/") ) 4. Provided example code to test one file: testCollette() Can't test all files this way since some do not have a Run "number" No common usage of this term between facilities (not likely either) 5. Example code copies into a flat file directory. Flat directories are discouraged by PRJ since the name space becomes quite unmanageable when many sample are present. Easier to build in support for hierarchy, such as in the Indra or Irena packages for IgorPro.
#11 1211898802 prjemian == SAXON XSLT == From: http://osdir.com/ml/text.xml.saxon.help/2005-07/msg00039.html {{{ To do schema-aware processing, and to get attributes with any type other than xdt:untypedAtomic, you need Saxon-SA. You then invoke the transformation as java com.saxonica.Transform -val source.xml style.xsl to invoke validation of the source document; its element and attribute nodes will then have a schema-derived type and tests like attribute(*, xs:string) will work. Michael Kay http://www.saxonica.com/ }}} From: http://saxon.sourceforge.net/ {{{ Saxon-SA is a commercial product available from Saxonica Limited (http://www.saxonica.com/). }}}
#11 1231303086 prjemian Chuck this whole web validation rubbish and rely on local system (UNIX/linux/cygwin/other) command line tools based on {{{xmllint}}}. Anyone who knows better tools is free to step in. Here is an example: {{{ xmllint --schema cansas1d.xsd bimodal-test1.xml }}} Also, schema-aware editors (such as oXygen or Eclipse) can validate files. It might still be nice to provide a web-based validation service.
#12 1253898881 prjemian Ticket #19 ([91-92]) further identifies this as a problem to be resolved.
#12 1253907113 ajj Should be fixed. Added appropriate post-commit script to subversion.
#12 1253914081 prjemian still getting errors, see attached figure
#12 1254071595 prjemian problem resolved now and tested - working as expected
#13 1253837740 prjemian Cameron Neylon, ISIS, Rutherford Appleton Laboratory, suggests a "CC0" public domain license: * http://creativecommons.org/publicdomain/zero/1.0/ * http://creativecommons.org/about/cc0 (“No Rights Reserved”) * http://sciencecommons.org/weblog/archives/2009/09/09/cc0-endorsed-nature/ Looks like the CC0 license is targeted at works just like ours. Note that choice of a CC0 license is irreversible.
#13 1364503450 prjemian Best CC choice today seems to be: * http://creativecommons.org/licenses/by/3.0/ Alternative is to apply the standard Argonne National Laboratory open source license. Example: {{{ Copyright � 2013, UChicago Argonne, LLC All Rights Reserved cansas1d-1.1 (The canSAS 1D XML standard v1.1 for SAS data) OPEN SOURCE LICENSE Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Software changes, modifications, or derivative works, should be noted with comments and the author and organization�s name. 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. 3. Neither the names of UChicago Argonne, LLC or the Department of Energy nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. 4. The software and the end-user documentation included with the redistribution, if any, must include the following acknowledgment: "This product includes software produced by UChicago Argonne, LLC under Contract No. DE-AC02-06CH11357 with the Department of Energy." * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * DISCLAIMER THE SOFTWARE IS SUPPLIED "AS IS" WITHOUT WARRANTY OF ANY KIND. NEITHER THE UNITED STATES GOVERNMENT, NOR THE UNITED STATES DEPARTMENT OF ENERGY, NOR UCHICAGO ARGONNE, LLC, NOR ANY OF THEIR EMPLOYEES, MAKES ANY WARRANTY, EXPRESS OR IMPLIED, OR ASSUMES ANY LEGAL LIABILITY OR RESPONSIBILITY FOR THE ACCURACY, COMPLETENESS, OR USEFULNESS OF ANY INFORMATION, DATA, APPARATUS, PRODUCT, OR PROCESS DISCLOSED, OR REPRESENTS THAT ITS USE WOULD NOT INFRINGE PRIVATELY OWNED RIGHTS. * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * THIRD-PARTY LICENSES THIS SOFTWARE MAY INCLUDE OR USE THIRD-PARTY SOFTWARE THAT HAVE OTHER LICENSE AGREEMENTS, NOTICES, OR TERMS AND CONDITIONS. THESE AGREEMENTS SHOULD BE INCLUDED WITH ANY THIRD-PARTY PACKAGES THAT ARE DISTRIBUTED WITH THIS SOFTWARE AND SHOULD ALSO BE AVAILABLE ON THE RESPECTIVE THIRD-PARTY WEB SITES. IT IS YOUR OBLIGATION TO READ AND ACCEPT ALL SUCH TERMS AND CONDITIONS PRIOR TO USE OF THE CONTENT. }}}
#13 1364509562 prjemian fixed in [311]
#14 1363408303 prjemian no takers so far
#15 1363392445 prjemian no takers so far, lowering its priority
#16 1253836920 prjemian resolved in changeset [89]. Looks like the SVN comment of that changeset did not close this ticket. Why is that?
#17 1344719189 prjemian due to coming multi-dimensional standard changes to this item may provoke more confusion
#18 1253835129 prjemian I responded: {{{ Provision for an optional time/date stamp on the SASdata is missing from the standard. Unintentional omission. We are gathering revisions for v1.1 and this is appropriate to add. Perhaps as an optional attribute to the SASdata element. Seems more common to retain exposure time than finish time. May just be a matter of precision since exposure times can vary from minutes to milliseconds. If one is concerned with the order of SASdata blocks, the only provision available at present is to use the SASdata/@name attribute to convey that information. }}}
#18 1344718683 prjemian implement as iso8601 standard
#18 1344719091 prjemian added as optional '''timestamp''' attribute of '''SASdata''', format is XML ''dateTime'' (ISO8601 standard)
#18 1344719364 prjemian fixed in [231]
#19 1253898634 prjemian See changesets [90], [91], and [92] for progress. This is the important comment from changeset [91]: Start to convert documentation to DocBook. Refs #19. This way, correct documentation can be kept with each revision of the standard. Note, this comment still did not get attached to this TRAC ticket.
#19 1253917308 prjemian Moving ahead with the transition of documentation from mediawiki to DocBook/v5.0. There is a WWW tool ([http://toolserver.org/~magnus/wiki2xml/w2x.php]) to convert between these formats but it always requires some hand-editing. See changesets [91-103] for more details so far.
#19 1254066634 prjemian (In [116]) mroe graphics for the DocBook documentation. Refs #19
#19 1254067051 prjemian (In [117]) add the case studies, reformat other things, refs #19
#19 1254071273 prjemian (In [118]) current PDF of manual, refs #19
#19 1254074916 prjemian (In [119]) table formatting, math typesetting, more content in the Preface and elements sections, refs #19
#19 1254075226 prjemian (In [120]) latest revision with all content committed. Still needs links connected and formatting ("'''" for example) but all content is now translated from wiki. Refs #19
#19 1254179348 prjemian (In [123]) more cross-references, refs #19
#19 1254233076 prjemian Alternatively, one can use [http://www.mediawiki.org/wiki/Extension:Pdf_Export PDF Export] to ''convert into PDF your MediaWiki pages.'' The extension works with (requires) the open source [http://www.htmldoc.org/ htmldoc] package.
#19 1254337174 prjemian (In [126]) prepare to move source files for documentation down one level. This should make it clearer how to find the manual. Refs #19
#19 1254337269 prjemian (In [127]) move source files for documentation down one level. This should make it clearer how to find the manual. Refs #19
#19 1254346410 prjemian (In [128]) more cross-references and formatting, first index entries, cleaned up the Makefile, refs #19
#19 1254520068 prjemian (In [129]) more cross-references, formatting, & indices, refs #19
#19 1254977014 prjemian (In [130]) more cross-references, formatting, & indices, refs #19
#19 1254978075 prjemian (In [131]) more cross-references, formatting, & indices, refs #19
#19 1255018662 prjemian (In [132]) make sure the canonical "cansas1d/1.0" is all lowercase in the documentation, refs #19
#19 1255031601 prjemian (In [134]) move the "elements" section, rename "definitions of terms" to "glossary," more cross-references, formatting, & indices, refs #19
#19 1255047340 prjemian (In [138]) more cross-references, formatting, & indices, refs #19
#19 1255125643 prjemian (In [140]) manual is nearly complete for v1.0 release, still a few problems to resolve (table+figure, code examples), refs #19
#19 1255126538 prjemian (In [141]) fresh build of PDF, rearranged and removed unnecessary sections, refs #19
#19 1255153089 prjemian (In [142]) manual ready for review by 1dwg, equations still not converted properly but intent is readable, fixes #19
#20 1253835878 prjemian Now that the WWW site is established, it is possible to use a namespace with a URL such as {{{http://www.smallangles.net/cansas1d/1.0}}}. Since the "cansas1d/1.0" standard has been released this will remain unchanged for the v1.0 standard. For the v1.1 standard and beyond, a conforming URI will be chosen. This should be one of the first steps in starting the v1.1 standard.
#20 1253836598 prjemian possible conforming choices for the v1.1 could be: * URN style: {{{urn:cansas-1d:1.1}}} * URL style: {{{http://www.smallangles.net/cansas1d/1.1}}} The URL can be used to advise about a WWW site that either provides the schema or the documentation. But, it is not required for the URL to actually exist. This causes confusion for those that assume the URL must exist. The URN conforms, is compact, and yet provides no other information about the location of the actual standard. URL is probably better. Better still if it describes an existing and available WWW page.
#20 1344718197 prjemian see: http://www.ibm.com/developerworks/xml/library/x-namcar/index.html
#20 1344718595 prjemian for consistency with the 1.0 standard and to avoid confusing those who implement either canSAS1d/1.0 or canSAS1d/1.1, change of the form of the namespace will not be made at this time best to make this change with an XML implementation of the multi-dimensional standard
#20 1351704200 prjemian proposition to change targetnamespace {{{ from cansas1d/1.1 to urn:cansas1d:1.1 }}} This means the XML file header would change from {{{ <SASroot version="1.1" xmlns="cansas1d/1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="cansas1d/1.1 http://www.cansas.org/svn/1dwg/trunk/cansas1d.xsd" > }}} to {{{ <SASroot version="1.1" xmlns="urn:cansas1d:1.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:cansas1d:1.1 http://www.cansas.org/svn/1dwg/trunk/cansas1d.xsd" > }}} Note the change from smallangles.net to cansas.org!
#20 1351796270 prjemian fixed by [262]
#21 1344719385 prjemian fixed in [231]
#22 1344715383 prjemian Perhaps we generalize a SASspectrum object, then set name="sample_transmission" or name="can_transmission".
#22 1344715612 prjemian On 2012-08-10, Steve King writes: ''We already have provision in the standard under '''SASsample''' for stating a fixed-wavelength transmission, so for consistency I think wavelength-dependent transmissions should really also go in the same place!''
#22 1344717379 prjemian Structure called '''data''' is too general if we are to specify the minimum array names to be found. Change to '''TSdata''': currently {{{ <SAStransmission_spectrum name="sample"> <TSdata><Lambda unit="A"> 2.238500 </Lambda><T unit="none"> 0.97901E+00 </T><Tdev unit="none"> 0.12E-01 </Tdev></TSdata> <TSdata><Lambda unit="A"> 2.316848 </Lambda><T unit="none"> 0.95479E+00 </T><Tdev unit="none"> 0.12E-01 </Tdev></TSdata> <TSdata><Lambda unit="A"> 2.397937 </Lambda><T unit="none"> 0.95020E+00 </T><Tdev unit="none"> 0.12E-01 </Tdev></TSdata> <!-- ... --> </SAStransmission_spectrum> }}}
#22 1344881345 prjemian 2012-08-13, Steve King wrote: ''To be brief: ''1) Could we not just use Tdata instead of TSdata? (matches Idata then?) ''2) I'm happy with <SAStransmission_spectrum name="sample"> and <...name="can"> ''Steve
#22 1363406582 prjemian fixed in [280]
#23 1364504504 prjemian replace trunk with v1.1 branch: see [308], [309], [310]
#23 1364533336 prjemian refs [313]
#23 1364592276 prjemian content from CHANGES.txt 2013-03-28: moved v1.1 branch back to trunk (replacement) * TRAC #13: using the Argonne Open Source License 2013-03-27: finishing up the bindings before moving back to trunk * removed java/maven-eclipse directory as indicated by java/README.txt file * TRAC #25: PHP code updated to generate v1.1 data files * TRAC #26: Python binding complete, reads both v1.0 and v1.1 * TRAC #28: IgorPro binding needs updating, should read both v1.0 and v1.1 * TRAC #29: FORTRAN binding needs to be updated (or withdrawn) * TRAC #30: Can't easily allow arbitrary order of data columns in Idata group * TRAC #31: began work on Java binding 2013-03-15: identified that v1.1 is a branch, not yet ready for release * cleanup XSLT and reduce to just one XSLT * clean up the examples, remove unnecessary material * remove the mediawiki directory, we are done with it now 2012-10-31: * TRAC #17: wontfix: clean up rules * TRAC #18: added timestamp attribute to SASdata and SAStransmission_spectrum * TRAC #20: slight change in format of namespace string and URL * TRAC #21: added {any} element at end of SASdata and SAStransmission_spectrum * TRAC #22: added SAStransmission_spectrum * TRAC #27: rebrand from smallangles.net to cansas.org * slight changes in documentation of units (Angstrom and Celsius) * restriction against using UNICODE is lifted * removed the Glossary
#23 1364595363 prjemian finishing work [313-321] before v1.1 release
#23 1364595955 prjemian * TRAC #32: re-wrote java binding documentation and dropped this file ([320])
#23 1364595989 prjemian fixed in [325]: canSAS 1D v1.1 is now released
#25 1363406403 prjemian fixed in [287]
#26 1363408067 prjemian fixed by [289]
#27 1351796284 prjemian fixed by [262]
#28 1364501931 prjemian fixed by [306]
#29 1364502242 prjemian fixed in [307] Since the FOTRAN binding does not check the namespace or version number, there is nothing much to update except some documentation strings.
#30 1363449967 prjemian One of the rules for Idata is picky but hard to change, that Qdev must appear *after* Idev in each Idata group. *If* that that order can be allowed to be arbitrary, we'll change the rule, otherwise it is important to note that order-of-appearance is very important. It is possible the desired flexibility may require a change from XSD Schema rules to Schematron rules and that's a major change.
#30 1363450382 prjemian Here's the answer about placing Qdev in an arbitrary position within the Idata group. It can't be done within XSD Schema without changing our rules a bit. The troublemaker comes when implementing the choice between using either Qdev or dQw & dQl (only Qdev -or- both dQw AND dQl). An additional bit of trouble comes from the <xsd:any> element (allows any arbitrary data column to be added). {{{ <complexType name="IdataType"> <sequence> <element name="Q" minOccurs="1" maxOccurs="1" type="tns:floatUnitType" /> <element name="I" minOccurs="1" maxOccurs="1" type="tns:floatUnitType" /> <element name="Idev" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" /> <xsd:choice> <!-- [ [Qdev] | [[dQw] | [dQl]] ] --> <element name="Qdev" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" /> <xsd:sequence> <element name="dQw" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" /> <element name="dQl" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" /> </xsd:sequence> </xsd:choice> <element name="Qmean" minOccurs="0" maxOccurs="1" type="tns:floatUnitType" default="0" /> <element name="Shadowfactor" minOccurs="0" maxOccurs="1" type="float" default="1.0" /> <xsd:any minOccurs="0" maxOccurs="unbounded" processContents="skip" namespace="##other" /> </sequence> </complexType> }}} Arbitrary order of elements is provided by replacing <xs:sequence> with the <xs:all> element. But the <xs:all> does not permit a <xs:choice> or a <xs:any>. That's why we have the current rules. <xs:all> can only contain annotations or elements. No <xs:choice> or <xs:any>. http://www.w3schools.com/schema/el_all.asp We could handle the Qdev vs. dQw & dQl situation by allowing all three and advising that use of all of them is not expected and could be unreliable. But, the valuable <xs:any> still blocks our goal since it can't be used in <xs:all>. To get all these, we'd have to shift to a different rule language, such as Schematron. NeXus made this shift for just such reasons of flexibility. I suggest that we do not do that for the 1D standard, but consider it for the new multi-D standard.
#31 1364447496 prjemian * referenced in changesets [302] & [303] * fixed in changeset [305] * need to rebuild jar file once the branch is restored to the trunk
#32 1364503562 prjemian wait to do this until **after** the branch is moved back to the trunk, then will have properly built JAR file
#32 1364595896 prjemian removed in [320] no longer needed due to re-write of java binding documentation
#34 1365771445 prjemian The Java JAXB binding will be affected by this change. After fixing both, remove and re-tag v1.1.
#34 1365772969 prjemian see [326-336]
Note: See TracReports for help on using and creating reports.