TechNet
Exportieren (0) Drucken
Alle erweitern
Dieser Artikel wurde maschinell übersetzt. Wenn Sie die englische Version des Artikels anzeigen möchten, aktivieren Sie das Kontrollkästchen Englisch. Sie können den englischen Text auch in einem Popupfenster anzeigen, indem Sie den Mauszeiger über den Text bewegen.
Übersetzung
Englisch

Ansprüche Transformation Regeln Sprache

 

Betrifft: Windows Server 2012

Die gesamtstrukturübergreifende Ansprüche Transformation können Sie die Brücke für Dynamic Access Control gesamtstrukturübergreifend Ansprüche durch Festlegen von Transformationsrichtlinien für die für gesamtstrukturübergreifende Vertrauensstellungen für Ansprüche. Die wichtigste Komponente der alle Richtlinien ist Regeln, die in Ansprüchen Transformation Regeln Sprache geschrieben werden. Dieses Thema enthält Details zu dieser Sprache und bietet eine Anleitung zum Erstellen von anspruchstransformationsregeln.

Windows PowerShell-Cmdlets für die Transformation für Richtlinien auf gesamtstrukturübergreifende Vertrauensstellungen Optionen einfache Richtlinien festlegen, die in gängigen Szenarien benötigt haben. Diese Cmdlets Übersetzen der Benutzereingaben in Richtlinien und Regeln in der Ansprüche Transformation Regeln Sprache, und klicken Sie dann in das vorgeschriebene Format in Active Directory gespeichert. Weitere Informationen zu Cmdlets für die Anspruchstransformation finden Sie unter der AD DS-Cmdlets für die dynamische Zugriffssteuerung.

Je nach der Konfiguration der Ansprüche und Anforderungen für die gesamtstrukturübergreifende Vertrauensstellung in Ihrer Active Directory-Gesamtstrukturen platziert möglicherweise Ihren Ansprüchen Transformationsrichtlinien komplexer als die Richtlinien, die von Windows PowerShell-Cmdlets für Active Directory unterstützt werden. Um solche Richtlinien effektiv erstellen zu können, ist es wichtig zu verstehen, die Ansprüche Transformation Regeln Sprachsyntax und Semantik. Diese Transformation Regeln Sprache ("die Sprache") in Active Directory ist eine Teilmenge der Programmiersprache, mit der Anspruchsanbieter Active Directory Federation Services für ähnliche Zwecke, und er verfügt über eine ähnliche Syntax und Semantik. Allerdings gibt es weniger Vorgänge zulässig sind, und zusätzliche Syntax Einschränkungen befinden sich in der Active Directory-Version der Sprache.

In diesem Thema wird kurz erläutert, die Syntax und Semantik der Ansprüche Transformation Regeln Sprache in Active Directory und Aspekte vorgenommen werden, wenn Sie Richtlinien erstellen. Es bietet verschiedene Beispiele für Regeln für Ihre ersten Schritte und Beispiele für eine falsche Syntax und die Nachrichten, die sie generieren, mit denen Sie die Fehlermeldungen zu entschlüsseln, wenn Sie die Regeln erstellen.

Windows PowerShell-Cmdlets für Active Directory: Dies ist die bevorzugte und empfohlene Methode erstellen und Ansprüche Transformationsrichtlinien festlegen. Diese Cmdlets ermöglichen Switches für einfache Richtlinien, und überprüfen Sie Regeln, die für eine komplexere Richtlinien festgelegt werden.

LDAP: Ansprüche Transformationsrichtlinien in Active Directory über das Lightweight Directory Access Protocol (LDAP) bearbeitet werden können. Dies ist jedoch nicht empfehlenswert, weil die Richtlinien mehrere komplexe Komponenten wurden und die Tools, mit denen Sie die Richtlinie vor dem Schreiben in Active Directory können nicht überprüft werden. Dies erfordert möglicherweise später eine beträchtliche Zeit, um Probleme zu diagnostizieren.

Hier ist eine kurze Übersicht über die Syntax und Semantik der Sprache:

  • Die Ansprüche Transformation Regelsatz besteht aus 0 (null) oder mehrere Regeln. Jede Regel verfügt über zwei aktive Teilen: Select-Liste von Bedingung und Regelaktion. Wenn die Select-Liste von Bedingung TRUE ergibt, wird die entsprechende Aktion ausgeführt.

  • Select-Liste von Bedingung verfügt über 0 (null) oder mehr Bedingungen auswählen. Alle der Bedingungen auswählen muss zu TRUE ausgewertet der Bedingungsliste wählen Sie "Wahr" ausgewertet.

  • Jede Bedingung auswählen verfügt über einen Satz von NULL oder mehr Bedingung übereinstimmenden. Alle der Bedingung übereinstimmenden müssen für die Bedingung wählen Sie "true" ergibt TRUE ergeben. Alle diese Aktionen sind für einen einzelnen Anspruch ausgewertet. Ein Anspruch, einen Bedingung auswählen gekennzeichnet werden kann ein Bezeichner und gemäß der Regelaktion.

  • Jede Bedingung übereinstimmenden gibt die Bedingung entsprechend der Typ oder Value oder ValueType des Anspruchs mit anderen Bedingungsoperatoren und Zeichenfolgenliterale.

    • Bei Angabe einer Bedingung übereinstimmenden für eine Wert, müssen Sie auch angeben eine Bedingung übereinstimmenden für einen bestimmten ValueType und umgekehrt. Diese Bedingung muss nebeneinander in der Syntax.

    • ValueType übereinstimmungsbedingungen muss bestimmte verwenden ValueType nur Literale.

  • Ein Regelaktion können einen Anspruch, der mit markiert ist, kopieren Sie eine Bezeichner oder geben Sie einen Anspruch basierend auf einen Anspruch, der mit einem Bezeichner markiert ist, und/oder Zeichenfolgenliterale angegeben.

Beispielregel

Dieses Beispiel zeigt eine Regel, die die Ansprüche Typ zwischen zwei Gesamtstrukturen zu übersetzen, vorausgesetzt, dass sie dieselben Ansprüche Werttypen und die gleichen Interpretationen für Ansprüche Werte für diesen Typ haben verwendet werden kann. Die Regel verfügt über eine entsprechende Bedingung und eine Problem-Anweisung, die Zeichenfolgenliterale und einem entsprechenden Ansprüche Verweis verwendet.

C1: [TYPE=="EmployeeType"]  
                 => ISSUE (TYPE= “EmpType”, VALUE = C1.VALUE, VALUETYPE = C1.VALUETYPE);
[TYPE=="EmployeeType"] == Select Condition List with one Matching Condition for claims Type.
ISSUE (TYPE= “EmpType”, VALUE = C1.VALUE, VALUETYPE = C1.VALUETYPE) == Rule Action that issues a claims using string literal and matching claim referred with the Identifier.

Es ist wichtig zu verstehen, den Common Language Runtime-Vorgang der Anspruchstransformation effektiv die Regeln zu erstellen. Die Common Language Runtime-Vorgang verwendet drei Sätze von Ansprüchen:

  1. Eingabe Ansprüche Satz: die Eingabe Satz von Ansprüchen, die die Ansprüche der Datenumwandlung zugewiesen werden.

  2. Arbeiten Ansprüche Satz: fortgeschrittene Ansprüche, die von gelesen und geschrieben während die Anspruchstransformation.

  3. Ausgabeforderungen Set: Ausgabe der Transformationsvorgang Ansprüche.

Hier wird eine kurze Übersicht über die Common Language Runtime Ansprüche Transformationsvorgang:

  1. Eingabeansprüche für Anspruchstransformation dienen zum Workingset Ansprüche zu initialisieren.

    1. Bei der Verarbeitung jeder Regel wird das Workingset der Ansprüche für die Eingabeansprüche verwendet.

    2. Die Auswahlliste für die Bedingung in einer Regel wird mit allen möglichen Sätze von Ansprüchen aus dem Arbeitssatz für Ansprüche verglichen.

    3. Jeder Satz übereinstimmender Ansprüche wird zum Ausführen der Aktion in der Regel.

    4. Die Ausführung einer Regel Ergebnisse in einen Anspruch, der mit der Ausgabe angefügt wird behauptet, und die Arbeit Ansprüche. Folglich wird die Ausgabe von einer Regel für nachfolgende Regeln im Regelsatz als Eingabe verwendet.

  2. Die Regeln im Regelsatz werden in sequenzieller Reihenfolge beginnend mit der ersten Regel verarbeitet.

  3. Wenn die gesamte Regelliste verarbeitet wird, wird festgelegten Ansprüche Ausgabe verarbeitet, um doppelte Ansprüche zu entfernen und für andere Sicherheitsrisiken. Die resultierende Ansprüche sind die Ausgabe einer Transformation Ansprüche.

Es ist möglich, Schreiben komplexe Anspruchstransformation auf die Laufzeit das vorherige Verhalten basieren.

Beispiel: Common Language Runtime-Vorgang

Dieses Beispiel zeigt die Common Language Runtime-Vorgang der Anspruchstransformation, der zwei Regeln verwendet.


     C1:[Type==”EmpType”, Value==”FullTime”,ValueType==”string”] =>
                Issue(Type==”EmployeeType”, Value==”FullTime”,ValueType==”string”);
     [Type==”EmployeeType”] => 
               Issue(Type==”AccessType”, Value==”Privileged”, ValueType==”string”);
Input claims and Initial Evaluation Context:
  {(Type= “EmpType”),(Value=”FullTime”),(ValueType=”String”)}
{(Type= “Organization”),(Value=”Marketing”),(ValueType=”String”)}
After Processing Rule 1:
 Evaluation Context:
  {(Type= “EmpType”),(Value=”FullTime”),(ValueType=”String”)}
{(Type= “Organization”), (Value=”Marketing”),(ValueType=”String”)}
  {(Type= “EmployeeType”),(Value=”FullTime”),(ValueType=”String”)}
Output Context:
  {(Type= “EmployeeType”),(Value=”FullTime”),(ValueType=”String”)}

After Processing Rule 2:
Evaluation Context:
  {(Type= “EmpType”),(Value=”FullTime”),(ValueType=”String”)}
{(Type= “Organization”),(Value=”Marketing”),(ValueType=”String”)}
  {(Type= “EmployeeType”),(Value=”FullTime”),(ValueType=”String”)}
  {(Type= “AccessType”),(Value=”Privileged”),(ValueType=”String”)}
Output Context:
  {(Type= “EmployeeType”),(Value=”FullTime”),(ValueType=”String”)}
  {(Type= “AccessType”),(Value=”Privileged”),(ValueType=”String”)}

Final Output:
  {(Type= “EmployeeType”),(Value=”FullTime”),(ValueType=”String”)}
  {(Type= “AccessType”),(Value=”Privileged”),(ValueType=”String”)}


Im folgenden finden spezielle Syntax für die Regeln:

  1. Leere Regelsatz keine Ausgabeansprüche ==

  2. Leere Select-Liste von Bedingung == jeder Anspruch entspricht der Liste der Bedingung auswählen

    Beispiel: Leere wählen Sie die Bedingungsliste

    Die folgende Regel entspricht jedes Anspruchs im Workingset.

    => Issue (Type = “UserType”, Value = “External”, ValueType = “string”)
    
  3. Leere Übereinstimmung Liste Wählen Sie == jeder Anspruch entspricht der Liste der Bedingung auswählen

    Beispiel: Leere Übereinstimmungsbedingungen

    Die folgende Regel entspricht jedes Anspruchs im Workingset. Dies ist die grundlegende "zulassen-All"-Regel, wenn es allein verwendet wird.

    C1:[] => Issule (claim = C1);
    

Ansprüche, die eine Gesamtstruktur eingeben

Die bereitgestellten von Prinzipalen, die sich in einer Gesamtstruktur eingehenden Ansprüche müssen sorgfältig überprüft werden, um sicherzustellen, dass wir zulassen oder nur die richtigen Ansprüche auszugeben. Falsche Ansprüche können die Sicherheit der Gesamtstruktur beeinträchtigen, und das sollte eine Rolle spielt, beim Erstellen von Transformationsrichtlinien für die für Ansprüche, die eine Gesamtstruktur eingeben.

Active Directory hat die folgenden Funktionen, um zu verhindern, dass Fehlkonfiguration von Ansprüchen, die eine Gesamtstruktur eingeben:

  • Wenn eine Gesamtstruktur-Vertrauensstellung wurde keine Ansprüche Transformation Richtlinie für die Ansprüche, die aus Gründen der Sicherheit eine Gesamtstruktur geben Sie löscht Active Directory die principal Ansprüche, die die Gesamtstruktur eingeben.

  • Wenn die Regel auf Ansprüchen ausgeführt, die eine Gesamtstruktur-Ergebnisse in Ansprüche eingibt, die nicht in der Gesamtstruktur definiert sind, werden die undefined Ansprüche aus die Ausgabeansprüche gelöscht.

Ansprüche, die verlassen einer Gesamtstruktur

Ansprüche, die verlassen einer Gesamtstruktur enthalten weniger Sicherheitsbedenken für die Gesamtstruktur als der Ansprüche, die die Gesamtstruktur eingeben. Ansprüche können die Gesamtstruktur als lassen – selbst wenn keine entsprechenden Ansprüche Transformation Richtlinie vorhanden ist. Es ist auch möglich, Ansprüche auszugeben, die nicht in der Gesamtstruktur als Teil des Transformieren von Ansprüchen, die die Gesamtstruktur belassen definiert sind. Dadurch wird die gesamtstrukturübergreifende Vertrauensstellungen mit Ansprüchen auf einfache Weise einrichten. Ein Administrator kann bestimmen, wenn Ansprüche, die die Gesamtstruktur eingeben müssen umgewandelt werden, und richten Sie die entsprechende Richtlinie. Beispielsweise kann ein Administrator eine Richtlinie festgelegt, wenn muss ein Anspruch an die Offenlegung von Informationen zu verhindern, dass ausblenden.

Syntaxfehler im anspruchstransformationsregeln

Wenn eine bestimmte Ansprüche Transformation-Richtlinie enthält eine Reihe von Regeln, die syntaktisch falsch ist oder wenn andere Syntax oder Speicher Probleme vorliegen, die Richtlinie ist ungültig. Dies ist anders als die oben genannten standardbedingungen behandelt.

Active Directory nicht die Absicht in diesem Fall ermitteln und behandelt ein Abgesicherter Modus, wo keine Ausgabeansprüche erzeugt diese Vertrauensstellung + Richtung des Durchlaufs. Eingreifen des Administrators ist erforderlich, um das Problem zu beheben. Dies kann passieren, wenn LDAP verwendet wird, um die Ansprüche Transformation-Richtlinie bearbeiten. Windows PowerShell-Cmdlets für Active Directory verfügen Überprüfung um zu vermeiden, schreiben eine Richtlinie mit Syntaxfehler.

  1. Es gibt mehrere Schlüssel Wörter oder Zeichen, die in dieser Sprache (bezeichnet als Terminals) sind. Diese werden angezeigt, der Language-terminals Tabelle weiter unten in diesem Thema. Die Fehlermeldungen werden die Tags für diese Terminals für Mehrdeutigkeit verwenden.

  2. Terminale können manchmal als Zeichenfolgenliterale verwendet werden. Allerdings kann eine solche Vorgehensweise in Konflikt mit der Sprachdefinition oder weisen unbeabsichtigten Konsequenzen. Diese Art der Verwendung wird nicht empfohlen.

  3. Die Regelaktion ist nicht möglich typkonvertierungen auf Werte von Ansprüchen und ein Regelsatz, der eine solche Regelaktion enthält, wird als ungültig angesehen. Dies würde einen Laufzeitfehler und keine Ausgabeansprüche erstellt werden.

  4. Wenn eine Aktion in einen Bezeichner, die nicht in der Select-Liste von Bedingung Teil der Regel verwendet wurde verweist, handelt es sich um eine ungültige Verwendung. Dies würde einen Syntaxfehler.

    Beispiel: Falsche Kennung Verweis
    die folgende Regel zeigt nicht den korrekten Bezeichner in Regelaktion verwendet.

    C1:[] => Issue (claim = C2);
    

  • Alle Ansprüche eines bestimmten Typs zulassen

    Genaue Typ

    C1:[type==”XYZ”] => Issue (claim = C1);
    

    Mithilfe von Regex

    C1: [type =~ “XYZ*”] => Issue (claim = C1);
    
  • Unterbinden einen bestimmten Anspruchstyp

    genauer Typ

    C1:[type != “XYZ”] => Issue (claim=C1);
    

    Mithilfe von Regex

    C1:[Type !~ “XYZ?”] => Issue (claim=C1);
    

Anspruchstransformationsregeln werden durch einen benutzerdefinierten Parser überprüft auf Syntaxfehler analysiert. Dieser Parser wird von zugehörigen Windows PowerShell-Cmdlets ausgeführt, bevor Regeln in Active Directory gespeichert. Fehler bei der Analyse Syntaxfehler, einschließlich der Regeln werden auf der Konsole gedruckt. Domänencontroller führen auch des Parsers vor der Verwendung von Regeln zum Transformieren von Ansprüchen, und sie die Fehler im Ereignisprotokoll protokollieren (Ereignisprotokoll Zahlen hinzufügen).

In diesem Abschnitt werden einige Beispiele für Regeln, die Fehler mit falscher Syntax und die entsprechende Syntax geschrieben werden, die vom Parser generiert werden.

  1. Beispiel:

    c1;[]=>Issue(claim=c1);
    

    Dieses Beispiel umfasst ein falsch verwendeten Semikolon anstelle von einem Doppelpunkt.
    Fehlermeldung:
    POLICY0002: Richtliniendaten konnte nicht analysiert werden.
    Zeilennummer: die Nummer 1, Spalte: 2, Fehler-Token:;. Befehlszeile: ' c1; [] = > Issue(claim=c1);'.
    Parserfehler: "POLICY0030: Syntaxfehler: Unerwartetes ';', erwartet eine der folgenden Optionen: ':'.'

  2. Beispiel:

    c1:[]=>Issue(claim=c2);
    

    In diesem Beispiel ist das ID-Tag in der Kopie Ausstellung-Anweisung nicht definiert.
    Fehlermeldung:
    POLICY0011: keine Bedingung in der Anspruchsregel entsprechen dem Kennzeichen Bedingung in der CopyIssuanceStatement: 'c2'.

  3. Beispiel:

    c1:[type=="x1", value=="1", valuetype=="bool"]=>Issue(claim=c1)
    

    "Bool" ist nicht mit einem Terminalserver in der Sprache, und es ist kein gültiger ValueType. Gültige Terminals sind in der folgenden Fehlermeldung aufgeführt.
    Fehlermeldung:
    POLICY0002: Richtliniendaten konnte nicht analysiert werden.
    Zeilennummer: die Nummer 1, Spalte: 39, Fehler-Token: "Bool".
    Zeile: "c1: [Typ =="X1"Wert"1", Valuetype == =="Bool"] = > Issue(claim=c1);".
    Parserfehler: ' POLICY0030: Syntaxfehler: Unerwartetes 'STRING', erwartet einen der folgenden: 'INT64_TYPE' 'UINT64_TYPE' 'STRING_TYPE' 'BOOLEAN_TYPE' 'BEZEICHNER'

  4. Beispiel:

    c1:[type=="x1", value==1, valuetype=="boolean"]=>Issue(claim=c1);
    

    Die Zahl 1 in diesem Beispiel ist kein gültiges Token in der Sprache und eine solche Vorgehensweise ist in Übereinstimmungskriterien nicht zulässig. Es muss in doppelte Anführungszeichen ein, um es zu eine Zeichenfolge machen eingeschlossen werden.
    Fehlermeldung:
    POLICY0002: Richtliniendaten konnte nicht analysiert werden.
    Zeilennummer: die Nummer 1, Spalte: 23, Fehler-Token: 1. Zeile: "c1: [Type =="X1", Wert == 1, Valuetype =="Bool"] = > Issue(claim=c1);'. Parserfehler: "POLICY0029: unerwartete Eingaben.

  5. Beispiel:

    c1:[type == "x1", value == "1", valuetype == "boolean"] => 
         Issue(type = c1.type, value="0", valuetype == "boolean");
    

    Dieses Beispiel verwendet ein doppeltes Gleichheitszeichen (==), anstatt ein einzelnes Gleichheitszeichen (=).
    Fehlermeldung:
    POLICY0002: Richtliniendaten konnte nicht analysiert werden.
    Zeilennummer: die Nummer 1, Spalte: 91, Fehler-Token: ==. Zeile: "c1: [Type =="X1", Wert =="1",
    Valuetype =="Boolean"] = > Problem (type=c1.type, Wert ="0", Valuetype =="Boolean");".
    Parserfehler: "POLICY0030: Syntaxfehler, unerwartete"==", erwartet einen der folgenden:"="

  6. Beispiel:

    c1:[type=="x1", value=="boolean", valuetype=="string"] => 
          Issue(type=c1.type, value=c1.value, valuetype = "string");
    

    Dieses Beispiel ist syntaktisch und semantisch richtige. Jedoch mithilfe von "Boolean" ein Zeichenfolgenwert an Verwirrung gebunden ist, und sollte daher vermieden werden. Wie bereits erwähnt, mithilfe von Language-Terminals, wie Ansprüche Werte möglichst vermieden werden sollte.

Die folgende Tabelle enthält den vollständigen Satz von Terminaldienste-Zeichenfolgen und die zugeordnete Sprache-Terminals, die in der Ansprüche Transformation Regeln Sprache verwendet werden. Diese Definitionen werden Groß-und Kleinschreibung UTF-16-Zeichenfolgen verwenden.

Zeichenfolge

Terminaldienste

"=>"

IMPLIZIEREN

";"

SEMIKOLON

":"

DOPPELPUNKT

","

DURCH KOMMAS

"."

PUNKT

"["

O_SQ_BRACKET

"]"

C_SQ_BRACKET

"("

O_BRACKET

")"

C_BRACKET

"=="

EQ

"!="

NEQ

"=~"

REGEXP_MATCH

"!~"

REGEXP_NOT_MATCH

"="

ZUWEISEN

"&&"

UND

"Problem"

PROBLEM

'Typ'

Type

"Wert"

Wert

"Valuetype"

WERTTYP

"Forderung"

ANSPRUCH

"[_A-Za-z][_A-Za-z0-9]*"

BEZEICHNER

"\"[^\"\n]*\""

ZEICHENFOLGE

"uint64"

UINT64_TYPE

"int64"

INT64_TYPE

"String"

STRING_TYPE

"boolean"

BOOLEAN_TYPE

Die folgenden Ansprüche Transformation Regeln Sprache wird in Form von ABNF angegeben. Diese Definition verwendet die Terminals, die in der vorherigen Tabelle zusätzlich zu den hier festgelegten ABNF Productions angegeben werden. Die Regeln in UTF-16 codiert werden müssen, und Vergleichen von Zeichenfolgen müssen als zwischen Groß-/Kleinschreibung behandelt werden.

Rule_set        = ;/*Empty*/
             / Rules
Rules         = Rule
             / Rule Rules
Rule          = Rule_body
Rule_body       = (Conditions IMPLY Rule_action SEMICOLON)
Conditions       = ;/*Empty*/
             / Sel_condition_list
Sel_condition_list   = Sel_condition
             / (Sel_condition_list AND Sel_condition)
Sel_condition     = Sel_condition_body
             / (IDENTIFIER COLON Sel_condition_body)
Sel_condition_body   = O_SQ_BRACKET Opt_cond_list C_SQ_BRACKET
Opt_cond_list     = /*Empty*/
             / Cond_list
Cond_list       = Cond
             / (Cond_list COMMA Cond)
Cond          = Value_cond
             / Type_cond
Type_cond       = TYPE Cond_oper Literal_expr
Value_cond       = (Val_cond COMMA Val_type_cond)
             /(Val_type_cond COMMA Val_cond)
Val_cond        = VALUE Cond_oper Literal_expr
Val_type_cond     = VALUE_TYPE Cond_oper Value_type_literal
claim_prop       = TYPE
             / VALUE
Cond_oper       = EQ
             / NEQ
             / REGEXP_MATCH
             / REGEXP_NOT_MATCH
Literal_expr      = Literal
             / Value_type_literal

Expr          = Literal
             / Value_type_expr
             / (IDENTIFIER DOT claim_prop)
Value_type_expr    = Value_type_literal
             /(IDENTIFIER DOT VALUE_TYPE)
Value_type_literal   = INT64_TYPE
             / UINT64_TYPE
             / STRING_TYPE
             / BOOLEAN_TYPE
Literal        = STRING
Rule_action      = ISSUE O_BRACKET Issue_params C_BRACKET
Issue_params      = claim_copy
             / claim_new
claim_copy       = CLAIM ASSIGN IDENTIFIER
claim_new       = claim_prop_assign_list
claim_prop_assign_list = (claim_value_assign COMMA claim_type_assign)
             /(claim_type_assign COMMA claim_value_assign)
claim_value_assign   = (claim_val_assign COMMA claim_val_type_assign)
             /(claim_val_type_assign COMMA claim_val_assign)
claim_val_assign    = VALUE ASSIGN Expr
claim_val_type_assign = VALUE_TYPE ASSIGN Value_type_expr
Claim_type_assign   = TYPE ASSIGN Expr   

Anzeigen:
© 2016 Microsoft