- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 01 Oct 2007 17:47:53 +0000
- To: public-sml@w3.org
- CC:
http://www.w3.org/Bugs/Public/show_bug.cgi?id=4819 ------- Comment #1 from johnarwe@us.ibm.com 2007-10-01 17:47 ------- This is needsAgreement because adding that statement would conflict with existing text in 3.4.3 SML reference schemes that are not SML-IF inter-document references saying "Third, when creating a new sml:ref scheme, authors MUST be explicit about whether the scheme is an SML-IF inter-document reference." Less obviously, the arguments around saying EPRs are not SMLIF idrs are valid for the SML-defined EPR scheme, and for "random" EPR content, but would not necessarily be valid for every reference scheme. If the reference scheme constrains things sufficiently to define exactly how its references are resolved, there would be no problem doing so in an SML-IF consumer. Just because we have not defined such a scheme yet is no cause to preclude its future definition. It would also exclude the case where the consumer has out of band knowledge about how to resolve EPRs (say a run-time option). If we feel the need to say something about "naked" EPRs, i.e. those not recognized as part of a reference scheme instance, then "MAY interpret as idrs" would be the strongest we could say. I have no problem doing that, but that is a very different semantic than what the summary proposed. Whether or not we decide to make that stmt however, it would be inappropriate to me to have SML-IF constrain what reference schemes (spec'd in SML) are allowed to define as their syntax and semantics. SML-IF could validly layer on addl requirements wrt SML, but I don't think it should be removing freedom granted in SML who "owns" the def of and reqts on reference scheme definitions.
Received on Monday, 1 October 2007 17:48:03 UTC