Is there somewhere that explains the major differences between the 2003 RDL spec and the new one released in November? I will be going through the two specs in detail in January looking at the differences but I was just wondering if there's a quick synopsis out there somewhere.
Are there any major differences?
Darren
I guess I'll answer my own post in case anyone else out there is interested.
First the end of the new spec has a very brief and incomplete lists of the changes.
The important changes I found were the following:
1) InteractiveWidth and InteractiveHeight subelements added to Report element.
2) Multivaluie and Hidden subelements added to ReportParameters element.
3) ConnectionProperties now support OLEDB-MD, DB2, XML, and ConnectString changed from string to Expression.
4) Custom element removed and replcaed by CustomProperties and CustomProperty elements.
5) Textbox new subelement of UserSort (a new element).
6) FixedHeader subelement added to ColumnGrouping, RowGrouping, TableHeader and Header elements.
7) SeriesGrouping now added Style as a subelement.
8) Removed HeightRatio, DepthRatio, GapDepth removed from ThreeDProperties
9) CustomReportItem completely overhauled.
10) A bunch of new elements supporting CustomReportItem including: AltReportItem, CustomData, DataColumnGroupings, DataRowGroupings, DataGroupings, DataGrouping, DataRows, DataRow, DataCell and DataValue (note that there are now TWO DataValue definitions in the spec, I find it bizarre that they would have two separately defined DataValue elements, but oh well.
11) Axis element has 5 subelements changed from string to expression type.
12) The Compliance Levels concept was removed.
13) Expressions and Aggregate Functions were fleshed out a little more.
In addition to the above mentioned changes there were some more smaller specific constraints changes to various elements.
Thats about everything I found.
Darren
|||Darren's list is a very good description of the changes.
A few additional comments:
#4 CustomProperties are way more powerful than the old Custom element (which btw, gets automatically upgraded into a CustomProperty element). You can use RDL expressions with aggregations in CustomProperties - so you are no longer limited to "passing through" static contents to the RenderingObjectModel / custom rendering extensions.
#10 DataValue element: if you check the underlying XSD, you will see that there is only one DataValue element defined. It is reused for both, CustomReportItem and Chart. However, in the chart case we only allow the Value portion at this point.
#13 There are various minor improvements (allow the usage of Guid fields directly in textboxes, groupings, RunningValues can now also be used in charts, etc.)
-- Robert
|||We also added so-called "extended field properties" to the RDL expression language - mainly targeted at AS/MDX queries. E.g. =Fields!Dimension.UniqueName
-- Robert
|||#10 DataValue element: if you check the underlying XSD, you will see that there is only one DataValue element defined. It is reused for both, CustomReportItem and Chart. However, in the chart case we only allow the Value portion at this point.
Regarding your statement above. Ok, that makes more sense. But why in the spec is it defined twice? Why not define it one place in the spec and put a constraint on it like was done with other elements. Because honsetly it is very confusing and not at all clear that it is the intention that these two elements are one and the same.
Take this from the point of view of someone developing an RDL parser from the spec (much the same as someone might do for the PDF spec), there is absolutely no way to get that intent.
#13 There are various minor improvements (allow the usage of Guid fields directly in textboxes, groupings, RunningValues can now also be used in charts, etc.)
Regarding this statement above can you point me to which pages in the spec explain this part. I saw a note to this effect in the back of the spec but found nowhere actually IN the spec that identified these changes. It doesn't show up under type definitions or under textbox, so I'm a little confused here.
Thanks for all your help.
|||#10: You are right - we should have only one DataValue element in the spec and explain the contraints in that place. Right now, you will find a comment on page 80 that says "Note: Since this is the same as the DataValue element in Chart ..." - but it is maybe confusing. We will update the document; it may take a few weeks till the changes are available on the web site.
#13: The Guid changes are mentioned on page 89 and on page 113. Note: just adding Guid to the list of supported datatypes and saying that it is treated as string implies that Guid fields can now be used everywhere throughout the RDL (textboxes, groupings, filters, even parameters - because they behave like string parameters).
-- Robert
|||Robert,
Once again I really thank you for your quick and informative responses. I do have a couple more questions (of course ;-) ).
With regards to GUID changes if I understand you correctly, anywhere their is a string type, a GUID can be used. If this is true it would be nice if that was noted on page 9 under Element Definition conventions where string is defined.
Another point on that page is that it states:
"String - A subelement or attribute with a string text value"
Does this imply that anything of type string needs to be handled as a string or attribute? ie. QueryParameter | Name is defined as a String Type but Reporting Services treats it as an attribute only, while most String Types are treated as subelements only. My question is this: by the letter of the spec I would need to handle all string types on consumption as either attributes or elements yet I don't think you will ever see DataSet | Collation for instance, as anything but a subelement. Can this ever be an attribute? Can QueryParameter | Name ever be an element? If not can this be cleared up in the spec as well?
Hope all my nit-picking isn't bothering you too much. I think the spec is very well done, I just need some clarification on some of these issues.
Darren
|||If there is a (mandatory) attribute that uniquely identifies an item (such as the Name attribute of a query parameter), it will always be represented as Xml attribute in the RDL representation.
Hence, QueryParameter.Name is always an attribute and can never be an element. Dataset.Collation can never be an Xml attribute because it is optional in the RDL spec.
If there are other items where it is not clear if they are represented as attributes or elements in the RDL file, you can also check directly in the XSD:
http://schemas.microsoft.com/sqlserver/reporting/2005/01/reportdefinition/ReportDefinition.xsd
-- Robert
No comments:
Post a Comment