W3C home > Mailing lists > Public > public-sml@w3.org > February 2008

[Bug 5462] Can sml:nilref="true" be specified on a non-SML reference?

From: <bugzilla@wiggum.w3.org>
Date: Wed, 13 Feb 2008 23:46:19 +0000
CC:
To: public-sml@w3.org
Message-Id: <E1JPRIx-0001IP-JK@wiggum.w3.org>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:56:09 UTC