[
Lists Home |
Date Index |
Thread Index
]
> But this is not a well-formed error. The first
> version of the namespaces recommendation does not use the term
> "well-formed" at all, and while the 1.1 version does, it is not used in
> this context.
This is perhaps more in the direction of what I was looking to clarify. My
focus was less on the issue of wellformedness and more on whether or not
these samples should generate a fatal error. But my question really revolves
around the ambiguity found in the XML-Rec regarding the wellformedness of
parsed entities [1]. "An internal general parsed entity is well-formed if
its replacement text matches the production labeled content. All internal
parameter entities are well-formed by definition."
I can't tell if this Wellformedness check is supposed to happen at the time
of construction of the replacement text or at the time of inclusion. My
guess would be that it should happen at the time of construction, and this
is supported by the addtional constraint that all productions must begin and
end in the same entity (i.e., you can't start an element in one entity and
end it in another). Does this apply to namespaces though?
If the wellformedness/ns processing step occurs at the point of construction
and not when the replacement text is included then I must presume that none
of these items are NS correct-- because the "bar" prefix is undeclared. The
only way to make them correct would be to include an NS decl in the entity
literal.
The reason I ask is because I am trying to patch the AElfred parser to check
for WFness of entity literals-- but I am not sure if I should be checking
WFness upon reading the literal or upon inclusion (or both?)
Thanks again,
Jeff Rafter
[1] http://www.w3.org/TR/REC-xml/#wf-entities
|
