W3C home > Mailing lists > Public > public-xml-id@w3.org > January 2005

Re: 5. xml:id error processing being a "must"

From: Norman Walsh <Norman.Walsh@Sun.COM>
Date: Wed, 05 Jan 2005 10:29:55 -0500
To: Ian Hickson <ian@hixie.ch>
Cc: public-xml-id@w3.org
Message-id: <87r7kzyjv0.fsf@nwalsh.com>
/ Ian Hickson <ian@hixie.ch> was heard to say:
| | An xml:id processor must assure that the following constraints hold
| | for all xml:id attributes:
| | ...
| | An xml:id error occurs for any xml:id attribute that does not
| | satisfy the constraints.
| |
| | The xml:id processor performs ID assignment on all xml:id
| | attributes, even those that do not satisfy the enumerated
| | constraints.
| | ...
| | A violation of the constraints in this specification results in an
| | xml:id error. Such errors are not fatal, but must be reported by the
| | xml:id processor to the application invoking it.
|
| The above implies that if "the application" does nothing with the
| error, the processor has to do work (detect the errors listed in
| section 4) but that work will then be ignored.

That's true. Of course, if the application and the processor are
tightly integrated, then it would be impossible to know whether the
processor checked for the errors or not. An efficient implementation
might choose not to check :-)

| Should the spec say that xml:id errors MAY simply be ignored? In
| effect, what's the point of the error checking? The following
| document:
|
|    <test xml:id="!%&(@!"/>
|
| ...is well-formed, and MUST result in a document representation where
| the element has the ID "!%&(@!", despite it being technically in
| xml:id error.

I'm reluctant to allow general purpose xml:id processors, like my own
SAX filter, to always ignore all errors and claim to be conformant.

                                        Be seeing you,
                                          norm

-- 
Norman.Walsh@Sun.COM / XML Standards Architect / Sun Microsystems, Inc.
NOTICE: This email message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information.
Any unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.

Received on Wednesday, 5 January 2005 15:30:26 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:53:49 UTC