Package eu.bandm.tools.dtm
Class AttributeChecks
java.lang.Object
eu.bandm.tools.dtm.AttributeChecks
- Direct Known Subclasses:
AttributeChecks_valueTemplates
Sorts all attribute
"check()" should be called for a particular SAX event with a fresh instance.
By explicitly calling
The location information in theses error messages is (opaquely) the one supplied on creation, because in SAX contexts it comes with only coarse granular anyhow.
This is separated from the check(), because in the meantime in particular contexts attribute errors can be healed (cf xslt "attribute value templates", "use-attribute-set" attribute, etc.)
// OLD The "ignore" set is introduced for the "use-attribute-set" attribute (and some more) from xsl. FIXME nötig !? besser einfach nach UNDEF, dann wieder raus !?!
TDOM has its own checks, compiled into the constructor code, but these are not so complete (currently eg. undeclared atts are not recognized),
ATTENTION: Attributes of type ID IDREF IDREFS ENTITY ENTITIES and NOTATION must follow the "name" production, see XML section 3.3.1.
Attributes of type NMTOKEN, NMTOKENS and ENUMERATION need only follow the nmtoken production.
A name is an nmtoken which STARTS with an alphabetic character or underscore "_" or colon ":". An NMTOKEN may additionally start with "." or "-" or a digit.
NamespaceName
from the SAX event attributes part
and from the DTM defintion into the appropriate diagnosis set ok
,
missing
, violateType
, violateFixed
,
undeclared
), according to the type check results.
"check()" should be called for a particular SAX event with a fresh instance.
By explicitly calling
sendErrorMessages_Undecl_Type_Fixed(MessageReceiver)
,
all undeclared, type-violating and fixed-violating attributes are
reported to the message channel with the given location
Missing attributes are not, but must be treated explicitly by the caller.
The location information in theses error messages is (opaquely) the one supplied on creation, because in SAX contexts it comes with only coarse granular anyhow.
This is separated from the check(), because in the meantime in particular contexts attribute errors can be healed (cf xslt "attribute value templates", "use-attribute-set" attribute, etc.)
// OLD The "ignore" set is introduced for the "use-attribute-set" attribute (and some more) from xsl. FIXME nötig !? besser einfach nach UNDEF, dann wieder raus !?!
TDOM has its own checks, compiled into the constructor code, but these are not so complete (currently eg. undeclared atts are not recognized),
ATTENTION: Attributes of type ID IDREF IDREFS ENTITY ENTITIES and NOTATION must follow the "name" production, see XML section 3.3.1.
Attributes of type NMTOKEN, NMTOKENS and ENUMERATION need only follow the nmtoken production.
A name is an nmtoken which STARTS with an alphabetic character or underscore "_" or colon ":". An NMTOKEN may additionally start with "." or "-" or a digit.
-
Field Summary
Modifier and TypeFieldDescriptionprotected final Attributes
protected final DTM.Element
protected final Location<XMLDocumentIdentifier>
protected Set<NamespaceName>
protected Map<NamespaceName,
Integer> protected Set<NamespaceName>
protected Set<NamespaceName>
protected Set<NamespaceName>
protected Set<NamespaceName>
-
Constructor Summary
ConstructorDescriptionAttributeChecks
(Attributes atts, DTM.Element elDef, Location<XMLDocumentIdentifier> loc) -
Method Summary
Modifier and TypeMethodDescriptionstatic String
boolean
check()
protected boolean
protected void
check_more_tokens
(String value, boolean mustBeName, NamespaceName elname, NamespaceName attname) protected void
check_one_token
(String value, boolean mustBeName, NamespaceName elname, NamespaceName attname) void
dump
(PrintStream p, boolean silentMode) protected void
dump1
(PrintStream p, Set<NamespaceName> set, String text) get_loc()
get_ok()
boolean
boolean
noErrors()
void
The attributes recognized as erronuous in XML sense, can later be healed when meant in a derived system, like xslt.
-
Field Details
-
nsn2index
-
missing
-
violateType
-
violateFixed
-
undeclared
-
ok
-
loc
-
atts
-
elDef
-
-
Constructor Details
-
AttributeChecks
-
-
Method Details
-
attValueByNamespaceName
-
get_missing
-
get_violateType
-
get_violateFixed
-
get_undeclared
-
get_ok
-
get_index
-
get_loc
-
check
public boolean check() -
noErrors
public boolean noErrors() -
noConstructionProhibitingErrors
public boolean noConstructionProhibitingErrors() -
check
-
check_one_token
protected void check_one_token(String value, boolean mustBeName, NamespaceName elname, NamespaceName attname) -
check_more_tokens
protected void check_more_tokens(String value, boolean mustBeName, NamespaceName elname, NamespaceName attname) -
dump
-
dump1
-
sendErrorMessages_Undecl_Type_Fixed
public void sendErrorMessages_Undecl_Type_Fixed(MessageReceiver<SimpleMessage<XMLDocumentIdentifier>> msg) The attributes recognized as erronuous in XML sense, can later be healed when meant in a derived system, like xslt. Then the categorization will be revisited. Therefore the generation of error messages must be postponed. The MISSING attributes are still postponed!
-