{9} tickets (34 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.

Id Type Owner Reporter Milestone Status Resolution Summary Description Posixtime
#1 task prjemian prjemian closed fixed documentation for cansasXML.ipf

Need to develop documentation for the IgorPro? support code. Is it better as a WWW page or a wiki page? Prefer WWW for now.

1204930795
#2 defect prjemian prjemian closed fixed error handling when no Qsas is found

cansasXML.ipf does not pass the error back up to the caller when there is no Qsas, Isas, Qdev, or Idev data in the chosen SASdata. This is not allowed by the cansas1d/1.0 standard and should be reported as an error.

Suggest printing a remark in the IgorPro? command history and passing a non-zero return code to the caller who should handle accordingly (by removing the data folder for the SASdata).

1204931061
#3 enhancement Jan Ilavsky prjemian closed fixed cansasXML.ipf lacks a GUI

The XML reader (cansasXML.ipf) does not have a GUI.

1204931158
#4 task prjemian prjemian closed fixed XMLwriter for IgorPro

Need to add a capability to export IgorPro? experiments to the cansas1d/1.0 XML format.

Can do this based on the XMLutils XOP.
Build this in as part of the cansasXML.ipf support.

Expect that exporter (XML writer) will find Qsas, Isas, ... same as what it deposits into root:Packages:CS_XMLreader:$TitleFolder

That will be the provided API.

1205433030
#5 defect prjemian prjemian closed fixed consistency change to the standard XML header

Change proposed to the XML header to promote consistency and to indicate a location where the standard can be found.

Above anything else, the URI named in the "xmlns" attribute ought to match with the 1st URI in "xsi:schemaLocation" attribute.

http://www.smallangles.net/wgwiki/index.php/cansas1d_documentation#required_XML_file_header

------------------------% existing %---------------------------------
<?xml version="1.0"?>
<SASroot version="1.0"
    xmlns="http://www.smallangles.net/cansas1d"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://www.smallangles.net/cansas1d                         http://svn.smallangles.net/svn/canSAS/1dwg/trunk/cansas1d.xsd"
    >
------------------------% existing %---------------------------------
------------------------% proposed %---------------------------------
<?xml version="1.0"?>
<SASroot version="1.0"
    xmlns="cansas1d/1.0"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="cansas1d/1.0 http://svn.smallangles.net/svn/canSAS/1dwg/trunk/cansas1d.xsd"
    >
------------------------% proposed %--------------------------------- 
1206035606
#6 defect prjemian prjemian closed fixed change names & order of columns in Idata

The present standard for the order of the columns in the SAS out put file disagrees with the order agreed at the meeting. This agreement was on human-readable (not by consensus on this point—there was one dissenter) 2-6 ordered columns (the dissenter wanted the information sequential, but did not dispute order), in the following order Q; I(Q)[; Idev(Q)[; Qdev(Q) [; Qmean(Q); ShadowFactor? (Q)]]]. The order of the columns WAS agreed, and for a reason: It was the one Steve and Ron used for their collaboration, the one IPNS and we use in our text outputs, and the one NIST uses in their text outputs, and the one indicating frequency of use. The history of this standard can be verified by looking at Steve and Ron’s original examples in http://svn.smallangles.net/svn/canSAS/1dwg/trunk/. Ken suggests a return in the standard to this order, with the columns in braces being optional, but the first two of them (Idev(Q) and Qdev in that order) very strongly recommended.

1206036540
#7 enhancement prjemian prjemian closed fixed allow arbitrary elements to be added in various places

Some facilities have additional information to be described within the XML file. The present model requires that all elements are declared explicitly in the XML Schema. Can we relax this requirement yet still validate with an XML Schema?

1206134661
#8 defect prjemian prjemian closed fixed disagreement in SAScollimation definition

The definition of SAScollimation has some disagreement between the XSD, the block diagrams, and the various XML example and template files.

Exactly where is distance?

SAScollimation
  distance    <-- XML Schema says
  aperture
    size
      x
      y
      z
    distance  <-- other things say

1209075958
#9 enhancement prjemian prjemian closed fixed allow for <any> in Idata

Seems generally useful to add an <any> element to the Idata structure. (http://www.smallangles.net/wgwiki/index.php/cansas1d_SASdata)

This would not break any existing code or definitions.

1209156602
#10 enhancement prjemian prjemian closed fixed suggestions for cansasXML.ipf from ISIS-LOQ

Users of the ISIS LOQ instrument software have begun using the cansas1d/1.0 (a.k.a. SASXML) format with IgorPro? "and are pretty happy." They contribute these suggestions as part of an email exchange today. Some are defects to be addressed, some are enhancement requests.

1210611984
#11 enhancement prjemian prjemian closed worksforme Web-based XML Schema validation method needs improvement

The instructions for validation of XML files against the cansas1d/1.0 XML Schema are sufficient but the validation result is not always in agreement with the tools provided in the Eclipse IDE. While setting up the initial site and instructions, it was found that some files which validated in Eclipse did not pass the WWW tool provided by http://www.xmlvalidation.com/. The diagnostics returned by that site pointed to problems that just did not exist.

We need a better validator.

Possibly one of these technologies?

  • SAXON XSLT
  • JAXB

It needs to be a web-server based technology and should obtain the cansas1d.xsd directly from the SVN repository (not provide a general XSD validation service or it may become too popular). Can it be hosted on smallangles.net? Explore first.

1211213252
#12 enhancement prjemian closed fixed TRAC admin stuff: SVN comments do not produce TRAC actions

TRAC can be configured so that well-chosen comments in SVN commits can produce TRAC actions.

Such as the SVN comment in Changeset [39] that fixes #10 could have automatically closed out the TRAC ticket. There is a TRAC configuration for this.

Also see changeset [26] for a refers to #8 that could have produced a timeline entry.

Another "feature" of TRAC is to add an email address to the CC: field so that any activity on that ticket will be emailed.

1211213750
#13 defect prjemian closed fixed Need to pick a license model

Perhaps either GNU Lesser General Public License or Creative Commons?

1231943337
#14 enhancement prjemian new input/output support for Matlab

suggestion at SAS2009 to create support for Matlab

1253307471
#15 enhancement prjemian new input/output support for C++

suggestion at SAS2009 to create support for C++

1253307529
#16 defect prjemian closed fixed ISIS files do not yet validate

Need to store wavelength dependence of transmission but current method to store in SASdata produces invalid files. Simple rearrangement does not work since the SASdata does not have Q or I data. Assigning to a local namespace also does not work since this would remove the only SASdata in the SASentry. Rules do not permit a <SASdata/> (empty) block.

How best to save this information? <SASnote> seems the only way for now.

Improve this for v1.1

1253307883
#17 task prjemian prjemian closed wontfix Clean up rules for v1.1 release

Some of the rules (such as redundant <any> elements and "name" attributes can be cleaned up for a v1.1 release. Also, collect bugs and enhancements.

1253307993
#18 defect prjemian prjemian closed fixed timestamp for SASdata or SASentry

Daniel Franke notes today in an email:

I can't find a timestamp associated with a SASdata or SASentry?! Such a timestamp (collection begin/end or begin and exposure time) would simplify to compare SASentry/SASdata-sections over time (think of tests for radiation damage in biological samples on repeated exposure of the same sample). For now it's not clear to me in which order SASdata-blocks were obtained; the tag-order in XML is, as far as I know, not significant and SASentry/Run is not limited to sequential numbers.
1253834807
#19 enhancement prjemian prjemian closed fixed documentation in version control

The documentation on the wiki describes the current version. Previous versions must have documentation available and the wiki does not look like the best way to preserve that.

Perhaps a "Print page to PDF" capability can be added to the wiki. Otherwise, the documentation should be moved to files maintained by version control and gathered/tagged by release version.

1253835351
#20 enhancement prjemian prjemian closed fixed namespace URI is non-standard

Daniel Franke writes:

... This is probably already known: 
reading the example files from the wiki, libxml2 keeps complaining

bimodal-test1.xml:4: namespace warning : xmlns: URI cansas1d/1.0 is not 
absolute
                xmlns="cansas1d/1.0"
                                    ^

The W3C Recommendation on Namespaces [1] has:
"2.2 Use of URIs as Namespace Names
[...]
 The use of relative URI references, including same-document references, in 
namespace declarations is deprecated."

Regards

	Daniel


[1] http://www.w3.org/TR/REC-xml-names/#iri-use
1253835666
#21 enhancement prjemian closed fixed add term element(s) to SASdata

An email discussion today with Daniel Franke provoked this suggestion (from me to Daniel):

Your comments bring to mind that other parameters may be useful yet still unforeseen for SASdata.  Perhaps an "any" element rule could be added to the SASdata, appearing either before or after (but not between) the Idata elements.  This would be [0..unbounded].  

Also, a SASentry/SASdata/term element similar to SASentry/SASprocess/term could be used to describe parameters that change between the SASdata blocks. In the NIST-SANS case (AF1410 steel ) on the wiki, one parameter that changes and is immediately known from data reduction is the angle of the sector average (either zero or 90). 
1253837206
#22 enhancement Jemian prjemian closed fixed support transmission spectra

ISIS has a need to store transmission spectra with the SASentry. This need is particular to TOF-SANS instruments. Currently, these spectra are stored as siblings to SASData using an XML foreign namespace. It would be easier if the canSAS defined these terms so that a foreign namespace is not required.

Separate data sets for "sample" and "can" are typical. Each would hold this kind of data:

Lambda (A) T (none) Tdev (none) 
2.238500  0.97901E+00  0.12E-01  
2.316848  0.95479E+00  0.12E-01  
2.397937  0.95020E+00  0.12E-01 
...

Suggest that we store this data similar to the 1-D SASdata, such as:

  <SAStransmission_spectrum name="sample">
   <data><Lambda unit="A"> 2.238500 </Lambda><T unit="none"> 0.97901E+00 </T><Tdev unit="none"> 0.12E-01 </Tdev></data>
   <data><Lambda unit="A"> 2.316848 </Lambda><T unit="none"> 0.95479E+00 </T><Tdev unit="none"> 0.12E-01 </Tdev></data>
   <data><Lambda unit="A"> 2.397937 </Lambda><T unit="none"> 0.95020E+00 </T><Tdev unit="none"> 0.12E-01 </Tdev></data>
   <!-- ... -->
  </SAStransmission_spectrum>
1344715191
#23 task prjemian closed fixed release v1.1 of the 1-D standard 1345832459
#24 enhancement prjemian closed fixed build the canSAS1d documentation using Sphinx 1345839256
#25 defect prjemian closed fixed update xmlWriter to v1.1 1346091097
#26 defect prjemian closed fixed update Python binding to v1.1 1346091131
#27 task prjemian closed fixed rebrand from smallangles.net to cansas.org 1351705671
#28 task prjemian prjemian closed fixed update IgorPro binding to v1.1 1363408252
#29 task prjemian closed fixed update Fortran binding to v1.1 1363408344
#30 enhancement prjemian prjemian closed wontfix allow arbitrary order of data columns in Idata group

Makes sense to report Q Qdev I Idev but the current rules require Q I Idev Qdev. Can this be allowed?

More to the point, must the order of data columns be exactly as described?

1363449856
#31 task prjemian prjemian closed fixed update Java binding to v1.1 1364426077
#32 defect jemian prjemian closed wontfix repair Example_canSAS_Reader.java in manual

The Example_canSAS_Reader.java code in the manual is not right.

For starters, there is no such net.smallangles.cansas1d.CanSas1dType.java

1364503292
#33 defect prjemian prjemian new errors in v1.1 documentation

errata

overview.rst: Examples and Case Studies

  • links to files are broken since the files have been moved
    • cansas1d.xml
    • bimodal-test1.xml
    • cansas1d-template.xml
    • W1W2.XML
    • cs_af1410.xml
  • change Also refer to canSAS TRAC ticket #47 to Also refer to canSAS subversion changeset [47]

additions

language bindings: FORTRAN

  • needs to handle SAStransmission_spectrum data
  • could benefit from a working example
  • show how to get I(Q)

language bindings: IgorPro?

  • needs to handle SAStransmission_spectrum data
  • consolidate the two notes at the start of the documentation
  • revise the order of sections
    • start with an example using CS_XmlReader(fileName)
    • then, prjTest_cansas1d()
    • then installation discussion
  • show how to get I(Q)

IgorPro? Graphical User Interface

  • revise to current status
  • change URL from .xor. to .xray.

The Intensity Problem

This section is out of place at this location. Where should it go?

1364656262
#34 defect prjemian prjemian closed fixed error in XML Schema

the ISIS Mantid team points out this error in the XML Schema:

<element name="Lambda " minOccurs="1" maxOccurs="1"    type="tns:floatUnitType" />

There is an extraneous space in the value of the name attribute

1365771322
Note: See TracReports for help on using and creating reports.