- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 13 Feb 2008 23:46:19 +0000
- To: public-sml@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=5462 ------- Comment #6 from johnarwe@us.ibm.com 2008-02-13 23:46 ------- Packaging this as a separate comment so it can be accepted/rejected separately of the preceding. 4.2.5's new second paragraph Processors MUST ignore an sml:nilref attribute when present on an element that is not an SML Reference [4.1.1 SML Reference], in which case the consumer MAY issue a warning to its invoker. looks to me like another case of mixing syntax and semantics. The syntax is discussed in 4.1.2, where any form of this probably belongs (since the definition of null SML reference depends on it being an SML ref via 4.1.2 condition 1, we currently have no name for an element such as <dummy sml:ref="false" slm:nilref="true"/> nor do I think we want to add one). Secondly there is the email discussion about "must ignore" to deal with. We need to either define 'processor' or change it (e.g. to model validator, since I see no more general term like SMLIF's "consumer"), that much seems clear. As I understand Sandy's point, if "processor" or "model validator" is the hunk of software (current def says "embodiment"), then "MUST ignore" says for example that you don't find out that sml:ref="false" sml:nilref="fred" was specified even after schema validation runs. fred is not a legal boolean value, but it must not be checked because of the must-ignore. PROPOSAL: delete 4.2.5 paragraph 2 (see comment 2 for text) add in 4.1.2, at the end, the following It is a consequence of the preceding that this specification assigns no meaning to the sml:nilref attribute when it is used on an element that is not an SML reference. Model validators MAY choose to warn their invokers should they detect this condition in a document.
Received on Wednesday, 13 February 2008 23:46:27 UTC