Skip to content

Conversation

@srutzky
Copy link
Contributor

@srutzky srutzky commented Oct 25, 2017

These changes mostly revolve around clarification regarding the new collations added in SQL Server 2017. There has been no mention of supplementary character support and that seemed odd. I did some testing and found that all new collations supported them, even without having the _SC option specified (which is great). I documented this in the following blog post:

All New Collations in SQL Server 2017 Implicitly Support Supplementary Characters

There are also some formatting and grammatical improvements.

In "What's New" page:

Updated line starting with "Two new Japanese collation families" to:

  1. clarify that the _VSS option applies to only the new collations.
  2. mention that the new collations do not have the _SC option due to all of them already supporting supplementary characters.

In "Collation and Unicode Support" page:

Added notes in at least 3 places about built-in supplementary character support in new version 140 collations.

Some grammatical improvements.

Fixed formatting and rearranged bullet points as several items (e.g. the 2 lists of what the SC flag can and cannot be applied to) somehow got grouped into one of them and were no longer separate items.

Also changed the way supplementary character support was denoted. It used to be just "SC collations", but the _SC flag in the collation name is no longer the sole indicator of a collation that supports supplementary characters: it is now _SC in the name or _140_ in the name. So, for the comparison chart of how the built-in functions work in SC and non-SC collations, I changed that to be "Supplementary Character-Aware (SCA)".

I removed the "etc" from the list of collation options (old line # 201, new line # 205) since there are no other options ( _SC doesn't count since any collation that would have _VSS would not have a variation also with _SC ).

In the "COLLATIONPROPERTY()" page:

Formatting consistency and note about _VSS in ComparisonStyle property.


Notes:

  1. I tried to find a consistent style, across several pages even, when indicating collation options / flags, and sadly, there really isn't any consistency. The "Collation and Unicode Support" page has multiple styles. I have seen (across multiple pages):

    • _BIN
    • (_BIN)
    • (BIN)
    • _BIN
    • BIN

    It would be nice if there was a style guide or some guidance / consensus on how to deal with this.

  2. I wasn't sure how to deal with the meta-data, or if I am even supposed to update it. I do think it is valid to at least have changed the SQL Server version number on the "Collation and Unicode Support" page to 2017 as it was still set to 2016. But the date and "author"? On two of the page I changed the "author" but not the "ms.author" to myself. If that was not supposed to be touched then it can be put back to "BYHAM". And I think I changed the date on one of them, and that can be put back to what it was if I am not supposed to set that to the date that I update the content.

    FWIW, I did try to find guidance on this, but many of the links on the main docs page are dead :-(

  3. There is a lot more to either clean up or add on the "Collation and Unicode Support" page, but I will come back later to tackle that as these changes were focused on the new collations.

Updated line starting with "Two new Japanese collation families" to:

1. clarify that the _VSS option applies to _only_ the new collations.
2. mention that the new collations do not have the _SC option due to all of them already supporting supplementary characters.
Added notes in at least 3 places about built-in supplementary character support in new version 140 collations.

Some grammatical improvements.

Fixed formatting and rearranged bullet points as several items somehow got grouped into one of them and were no longer separate items.
@msftclas
Copy link

msftclas commented Oct 25, 2017

CLA assistant check
All CLA requirements met.

@craigg-msft
Copy link
Contributor

@srutzky can you please change this PR or submit a new PR without changes to the author meta data. thank you.

@srutzky
Copy link
Contributor Author

srutzky commented Oct 26, 2017

@craigg-msft Absolutely. Sorry about that. I got confused when I noticed in the history on one page that "BYHAM" had updated that meta-data and so then I thought that I was supposed to do that as well. But I later saw other pages still with "BYHAM" as the author while others had updated those pages more recently. Is there guidance on this somewhere? Should I update the "ms.date" in the meta-data or leave that alone as well? Is that the document revision date or something else?

@craigg-msft
Copy link
Contributor

@srutzky no problem. ya, the ms.date is the revision date. We don't worry about tweaking it every time there is a tiny edit but anytime there is something measurable. Its not an exact science. So you changing the date is ok and helpful.

Even if the particular changes for this file in this PR aren't "significant", the date still should have been changed when I did make significant updates via MicrosoftDocs#161 on Oct 15th. At least this way there is consistency across the 3 files given that the changes all revolve around the new Japanese / _VSS collations.
@srutzky
Copy link
Contributor Author

srutzky commented Oct 27, 2017

@craigg-msft Ok, I think everything is now the way it should be. Please take a look and let me know if there is anything else I need to clean up. Thanks!

@craigg-msft
Copy link
Contributor

Thank you @srutzky

@craigg-msft craigg-msft merged commit 9ca1dce into MicrosoftDocs:live Oct 31, 2017
@srutzky srutzky deleted the SRutzky-NewCollationsIn2017 branch November 6, 2017 15:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants