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

discussion on : 5544 Why does SML require that the target of SMLURI be an XML element?

From: Kumar Pandit <kumarp@windows.microsoft.com>
Date: Wed, 30 Apr 2008 17:35:27 -0700
To: "public-sml@w3.org" <public-sml@w3.org>
CC: Kumar Pandit <kumarp@windows.microsoft.com>
Message-ID: <AB1E5627D2489D45BD01B84BD5B9004602C87078DE@NA-EXMSG-W601.wingroup.windeploy.ntdev.microsoft.com>
The WG discussed this issue during the conf call on 4/24/08 and decided to stick to the original resolution of the bug (that is, resolve 'later'). During the call we decided to add a summary of our discussion to the bug.

Here is a summary of the discussion (rephrased). Please let me know if you would like to add/modify any of the points below. I plan to add this to the bug by eod Thu.


1.    The spec defines target to be an element. In order to find if the target element is present, one must descend into the document. Thus, the statement that descent is not required to verify targetRequired is not entirely correct.

2.    The targetRequired constraint does not exist in isolation. It is one of the constraints defined by the SML spec. A ref can participate in any combination of targetRequired/targeType/targetElement/acyclic/id constraints/Schematron constraints. The behavior of constraints other than targetRequired is undefined when the target is not xml.

3.    One could argue that deref() could be different dependent upon whether we are evaluating targetRequired or other constraints. This seems fragile given that the same ref can have both targetRequired and some other constraints.

4.    SML uses xpath 1.0 augmented with deref() function for defining id constraints/Schematron constraints. Is XPath behavior defined when non-xml entities involved?

5.    The entire SML spec is written with the scope restricted to xml documents. Allowing non-xml documents to be a part of the model will require rewriting much of the spec to account for that.
Received on Thursday, 1 May 2008 00:42:23 UTC

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