Lists Home |
Date Index |
- From: Tyler Baker <email@example.com>
- To: firstname.lastname@example.org
- Date: Sat, 29 Aug 1998 02:59:16 -0400
When validating IDREF and IDREFS values for an attribute the following
constraint is stated:
Validity Constraint - IDREF
Values of type IDREF must match the Name production, and values of type
IDREFS must match the Names) production; each Name must match the value
of an ID
attribute on some element in the XML document; i.e. IDREF values must
match the value of some ID attribute.
Does this mean that you need to have the entire document parsed before
you can make the check that the value of the ID matches the ID of some
element in the document?
If this is true, then for validating parser implementations you will
first need to build an in memory parse tree using a non-validating
parser and then validate the document by recursively traversing the
parse tree. For large documents that wish to be validated, this seems
like a major performance and memory problem, especially in memory hungry
languages like Java.
Besides this production, I cannot see any other production in the spec
which prevents a validating parser from just validating the document
from a stream (at least for the implementation I am working on).
Perhaps this particular constraint should be relaxed so that this sort
of validating can be done at a higher level as many application
developers may want the benefits of validation without the obvious
I am not an SGML expert, so maybe someone here can give me some
historical reason for why the XML spec needs to have ID's or at least
ID's that have not previously been declared in the document when an
IDREF is encountered.
Thanx in advance,
xml-dev: A list for W3C XML Developers. To post, mailto:email@example.com
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/
To (un)subscribe, mailto:firstname.lastname@example.org the following message;
To subscribe to the digests, mailto:email@example.com the following message;
List coordinator, Henry Rzepa (mailto:firstname.lastname@example.org)