This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 6191 - ambiguity in rule binding semantics
Summary: ambiguity in rule binding semantics
Status: RESOLVED FIXED
Alias: None
Product: SML
Classification: Unclassified
Component: Interchange Format (show other bugs)
Version: LC
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Virginia Smith
QA Contact: SML Working Group discussion list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2008-10-30 00:44 UTC by John Arwe
Modified: 2008-11-13 07:23 UTC (History)
1 user (show)

See Also:


Attachments

Description John Arwe 2008-10-30 00:44:57 UTC
One of the COSMOS JUnits that fails, http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cosmos/tests/resource-modeling/org.eclipse.cosmos.rm.validation.tests/src/test-resources/others/rulesWithMultiplePattern.xml?root=Technology_Project&view=markup , appears to have fallen into a hole in the current SML spec.

The test case defines a single rule binding 
   <ruleBinding>
    	<documentAlias>/Units/DatabaseServer</documentAlias>
    	<ruleAlias>DatabaseServerRules</ruleAlias>
    </ruleBinding>
and an instances/document member with an alias of 
      <docinfo>
        <aliases>
          <alias>http://interop.serviceml.org/Units/DatabaseServer</alias>
        </aliases>
      </docinfo>
and a model base URI of
    <baseURI>
		http://interop.serviceml.org
    </baseURI>

The test case fails because it expects to find one rule document bound to the instance document whose alias is given above, and the code says zero are bound.

If one assumes that each <documentAlias> contains a URI reference (sic), then the test case's assumption about expected results would be consistent.

If on the other hand one assumes that SML's use of the term "URI prefix" in 5.4.2 was intended to communicate that each <documentAlias> contains an "absolute URI" prefix, then its value should not be transformed to absolute.

The same issue exists for <ruleAlias>

I believe the relevant sections are:
5.3.1 http://www.w3.org/TR/sml-if/#URI_equality
5.3.4 http://www.w3.org/TR/sml-if/#URI_Processing
5.4.1 http://www.w3.org/TR/sml-if/#URI_prefix_matching 
5.4.2 http://www.w3.org/TR/sml-if/#Rule_Bindings_Definition

If nothing else, this test case makes it clear that we need to clarify how these URIs (or URI references, if those are allowed) are treated in the spec.  We spent quite a bit of time scrutinizing document aliases, but relatively little on these.

Note that 5.3.4 does not list <ruleAlias> or <documentAlias> contents as "URIs subject to SML-IF URI processing", the usual code word for "it's an alias", one of the implication of which -is- that relative references are allowed.  If the intent is that relative references are allowed in this context, we likely need to amend the rules on when a base URI is required in SML-IF as well.
Comment 1 John Arwe 2008-11-06 19:56:09 UTC
11/6 telecon agreed on the following revision.

smlif 5.4.2, betw existing parag 2 and 3, add: 

Note: Since the URI prefixes specified as ruleAlias and documentAlias elements are aliases, they are subject to all of the processing for aliases as described in [5.3.3].  For example, if they are relative references then they would be transformed to absolute URIs before comparison.
Comment 2 Virginia Smith 2008-11-13 07:23:05 UTC
Fixed per comment #1.