W3C home > Mailing lists > Public > public-sml@w3.org > October 2007

[Bug 4819] Append to 3.3.2 \"Consumers MUST NOT interpret wsa:address \" the phrase \"or any other schemes other than uri\"

From: <bugzilla@wiggum.w3.org>
Date: Mon, 01 Oct 2007 17:47:53 +0000
To: public-sml@w3.org
Message-Id: <E1IcPN3-0000uo-TG@wiggum.w3.org>


------- 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:24:23 UTC