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

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

From: Pratul Dublish <PRATULD@microsoft.com>
Date: Fri, 8 Feb 2008 10:30:13 -0800
To: Sandy Gao <sandygao@ca.ibm.com>
CC: "public-sml@w3.org" <public-sml@w3.org>
Message-ID: <05EB77839C793348A2BA6837783D1F8313C1B2E5ED@NA-EXMSG-C124.redmond.corp.microsoft.com>
inline

From: Sandy Gao [mailto:sandygao@ca.ibm.com]
Sent: Friday, February 08, 2008 9:55 AM
To: Pratul Dublish
Cc: public-sml@w3.org
Subject: RE: [Bug 5462] Can sml:nilref="true" be specified on a non-SML reference?


> I don't see a problem here since the "MUST ignore" is directed at
> SML validators and not at XML Schema processors.

Schema and Schematron processing is part of SML validation.
[Pratul] Yes, but the normative statements in the SML spec are directed at SML validators. We do not determine the behavior of Schematron processor or XML Schema validators - this is done by the Schematron and XML Schema specs


sml:nilref should only be ignored in the context of "is this *thing* a null reference?" It should not be ignored in any other context.
[Pratul] Agreed, and this is pretty clear in the statement that
Processors MUST ignore an sml:nilref attribute when present on an element that is not an SML Reference [4.1.1 SML Reference], ...


This is also related to 5406. We are talking about data/semantics here (what's a null ref), which should not be described as "processors must".
[Pratul] You may be correct here.


Thanks,
Sandy Gao
XML Technologies, IBM Canada
Editor, W3C XML Schema WG<http://www.w3.org/XML/Schema/>
Member, W3C SML WG<http://www.w3.org/XML/SML/>
(1-905) 413-3255 T/L 313-3255


Pratul Dublish <PRATULD@microsoft.com> wrote on 2008-02-08 10:46:59 AM:

> I don't see a problem here since the "MUST ignore" is directed at
> SML validators and not at XML Schema processors.
>
> From: public-sml-request@w3.org [mailto:public-sml-request@w3.org]
> On Behalf Of Sandy Gao
> Sent: Friday, February 08, 2008 7:26 AM
> To: public-sml@w3.org
> Subject: Re: [Bug 5462] Can sml:nilref="true" be specified on a non-
> SML reference?
>
>
> Michael typed in IRC some text related to this topic. It may be
> worthwhile to take a look there.
>
> > Processors MUST ignore an sml:nilref attribute when present on an
> element that
> > is not an SML Reference [4.1.1 SML Reference], ...
>
> I would want to avoid "MUST ignore", because it's not ignored in, e.
> g., schema validation, rule checking, etc. Maybe something like "has
> no effect" is more appropriate. ("No effect" should already be a
> consequence from it's normative definition/semantics, so no need to
> use "MUST".)
>
> Thanks,
> Sandy Gao
> XML Technologies, IBM Canada
> Editor, W3C XML Schema WG
> Member, W3C SML WG
> (1-905) 413-3255 T/L 313-3255
>

>
> bugzilla@wiggum.w3.org
> Sent by: public-sml-request@w3.org
> 2008-02-07 07:03 PM
>
> To
>
> public-sml@w3.org
>
> cc
>
> Subject
>
> [Bug 5462] Can sml:nilref="true" be specified on a non-SML reference?
>
>
>
>
>
>
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=5462
>
>
> virginia.smith@hp.com changed:
>
>           What    |Removed                     |Added
> ----------------------------------------------------------------------------
>           Keywords|editorial                   |needsReview
>
>
>
>
> ------- Comment #2 from virginia.smith@hp.com  2008-02-08 00:03 -------
> Section 4.2.5 now reads (last sentence is new):
>
> 4.2.5 Null SML References
>
> An null SML reference is an explicit declaration of intent by the document
> author that the SML reference itself does not exist, and a
> processing directive
> (not a hint) to processors not to attempt to recognize any referenceschemes in
> it. If an SML reference is recognized as null, then processors MUST
> NOT attempt
> to resolve it.
>
> 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.
Received on Friday, 8 February 2008 18:30:28 UTC

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