Subclasses of AbstractLangString serialized differently in XML and RDF. Due to this inconsistency, SHACL shapes cannot validate most of the official examples that have displayName, dataSpecificationIec61360 preferred name, ...

XML

Let's see an example in XML: maximal AssetAdministraionShell XML example

In this example to have displayName we have:

<displayName>
  <langStringNameType>
    <language>de</language>
    <text>something_1e73716d</text>
  </langStringNameType>
</displayName>

and to have dataSpecificationIec61360 preferred name we have:

<preferredName>
  <langStringPreferredNameTypeIec61360>
    <language>zh-cmn-Hans-CN</language>
    <text>something_5282e98e</text>
  </langStringPreferredNameTypeIec61360>
  <langStringPreferredNameTypeIec61360>
    <language>en-GB</language>
    <text>Something random in English 5b15c20d</text>
  </langStringPreferredNameTypeIec61360>
</preferredName>

RDF

Now let's look at the RDF
maximal AssetAdministraionShell RDF/Turtle example

Here to have displayName we have:

<https://admin-shell.io/aas/3/0/Referable/displayName> [
    rdf:type aas:LangStringNameType ;
    <https://admin-shell.io/aas/3/0/AbstractLangString/language> "de"^^xs:string ;
    <https://admin-shell.io/aas/3/0/AbstractLangString/text> "something_1e73716d"^^xs:string ;
] ;

However, if we want to follow the same pattern as we have in XML we should have something like this:

<https://admin-shell.io/aas/3/0/Referable/displayName> [
    rdf:type aas:LangStringNameType ;
    <https://admin-shell.io/aas/3/0/LangStringNameType/language> "de"^^xs:string ;
    <https://admin-shell.io/aas/3/0/LangStringNameType/text> "something_1e73716d"^^xs:string ;
] ;

Indeed this is what SHACL states:

aas:LangStringNameTypeShape a sh:NodeShape ;
    sh:targetClass aas:LangStringNameType ;
    rdfs:subClassOf aas:AbstractLangStringShape ;
    sh:property [
        a sh:PropertyShape ;
        sh:path <https://admin-shell.io/aas/3/0/LangStringNameType/text> ;
        sh:datatype xs:string ;
        sh:minCount 1 ;
        sh:maxCount 1 ;
        sh:maxLength 128 ;
    ] ;
.

For this reason, the official example is actually incorrect. This is the same for other cases like dataSpecificationIec61360.
I know that Ontology workgroup is working on a new representation, but regardless, IMO, if the effort to fix this is low, it would be better to fix it for now. We can fix by correcting the examples, or by correcting the SHACL shape.
This issue doesn't appear in JSON serialization.