RE: SMLIF inter-document reference proposal

Ginny and all,

I should have included an "executive summary" of the proposal.

There were 4 categories of changes:

1. Editorial

Fix minor problems, inconsistencies, etc.

2. Formal rules

Formal rules are organized into a bulleted list, because connections 
between the old 3.4.x sections were not clear to me. We can of course 
choose to use prose if we think that's easier to read.

3. Not dependent on xs:anyURI

Similar to recognizing SML references, people want to be able to recognize 
those URI references that should get the base+alias treatment, without 
having to perform schema assessment.

4. The term "inter document reference"

This is the main change in this proposal, to get rid of this term. I 
believe the term was misused. In the current draft, being an IDR means:
- It can use the "base URI"
- It can be compared against aliases

Both of these only apply to some (and not all) URI references, which is 
only a subset of all possible IDRs.

What we really need is to specify, for a subset of URI references, how 
base URI and aliases are used to help achieve inter-op. We could use a 
term to denote that subset. I chose not to,
- It's hard to find one.
- Because reference scheme definitions already need to clearly specify how 
URI references (if used) are resolved, then "is this URI reference in the 
subset" should already be clear from the scheme definition. This removes 
the need to define a term T and for "every scheme to claim whether it's an 
T".


Now to answer your specific questions...

> 1 - Are you proposing that the term 'interdocument reference' be 
> changed to 'URI Reference'?

Or more precisely, the term IDR is removed, with no new term defined. It 
becomes "URI references that satisfy these conditions".

> Can we keep the term 'interdocument 
> reference' in place just for now until we agree to the changes you 
> propose and then decide on the specific term later? This new term 
> was confusing me since it is being overloaded.

I actually think IDR is confusing, which was the main motivation behind 
this proposal. I'm not using "URI reference" in any new way. I think I 
always qualify it when referring to our special URI refs.

> 2 - About URI (interdocument ref) Processing. The URIs are processed
> by the SML-IF producer who constructs the document aliases when 
> packaging up the model into an SML-IF document. I always envisioned 
> that the SML-IF consumer would unpack the SML-IF document into its 
> own environment, including 'adjusting' the interdocument references 
> to fit the consuming environment using the document aliases.

How packing and unpacking is done is not the focus of the proposal; and I 
don't think it's the focus of the IF spec either. IF is really about how 
everyone can interpret the same IF document in the same way. This is done 
in terms of providing answers to questions like "how to match URIs; how to 
bind rules; how to bind schemas; etc.", *if* validation were to be 
performed over the packaged model.

> One question - do you see an SML validator 
> processing an SML-IF document as is?

In implementations, I don't know. A consumer may want to do this for 
performance reasons. For example, it validates IF documents as they come 
in before or while unpacking them and storing them away.

> For example, in "URI Reference 
> Processing", step 4.b., why would a fragment identifier be followed 
> to grab non-root targets except by an SML model validator?

First of all, this is not new in this proposal. The old 3.4.6 had 
something similar. :-)

I think I agree that 4.b should be stated slightly differently. Instead of 
saying "otherwise follow", maybe it should be "otherwise how to find 
target(s) in D is defined in the corresponding schema definition"?

> 3 - Along the same lines, on page 5 is the following which mentions 
> an unresolved SML reference. We don't know if this is really an 
> unresolved SML reference or not. The user may request that the 
> producer not include this document and/or the document could 
> actually be located on the consuming end when the SML model is 
> processed by an validator.

In that case that target document is not part of the interchange set, 
hence not part of the SML model being processed. IF can only provide 
inter-op for the packaged model. I agree in this case saying it's 
"unresolved SML reference" is a bit more than what SML-IF is about (SML-IF 
only knows that the URI reference in question doesn't have a target in the 
packaged model), but this is an example in a non-normative, so I think 
"useful" may be more important than "accurate", especially when it's not 
wrong. :-) (It is a fact that an SML model is packaged in this example, 
and the particular SML reference is unresolved in this model.)

Thanks,
Sandy Gao
XML Technologies, IBM Canada
Editor, W3C XML Schema WG
Member, W3C SML WG
(1-905) 413-3255 T/L 313-3255
 



"Smith, Virginia (HP Software)" <virginia.smith@hp.com> 
2007-11-15 09:52 PM

To
<public-sml@w3.org>, Sandy Gao/Toronto/IBM@IBMCA
cc

Subject
RE: SMLIF inter-document reference proposal






Sandy,
 
Some comments from my first reading. In general, I am in agreement with 
what I think you are proposing. I would want to see the final edited 
SML-IF spec again to make sure since it is a little hard to judge this 
way.
 
Just a note: the diff document is based on an older copy of the spec. The 
section major number is generally +2 from what you see in your diff doc. 
Some text has also changed since bugs 4755, 4819, 5119, 5114, 5117 are 
closed.
 
1 - Are you proposing that the term 'interdocument reference' be changed 
to 'URI Reference'?  Can we keep the term 'interdocument reference' in 
place just for now until we agree to the changes you propose and then 
decide on the specific term later? This new term was confusing me since it 
is being overloaded.
 
2 - About URI (interdocument ref) Processing. The URIs are processed by 
the SML-IF producer who constructs the document aliases when packaging up 
the model into an SML-IF document. I always envisioned that the SML-IF 
consumer would unpack the SML-IF document into its own environment, 
including 'adjusting' the interdocument references to fit the consuming 
environment using the document aliases. The process of matching the 
correct document to each SML reference is covered in this section. One 
question - do you see an SML validator processing an SML-IF document as 
is? For example, in "URI Reference Processing", step 4.b., why would a 
fragment identifier be followed to grab non-root targets except by an SML 
model validator?
 
3 - Along the same lines, on page 5 is the following which mentions an 
unresolved SML reference. We don't know if this is really an unresolved 
SML reference or not. The user may request that the producer not include 
this document and/or the document could actually be located on the 
consuming end when the SML model is processed by an validator. Wouldn't 
this just be an unresolved interdocument reference?
The |↑fragment-free part of the↑ reference|↓:↓
http://www.university.example.org/Universities/Capella/Courses.xml
 #xmlns(u=http://www.university.example.org/ns)
  xpointer(/u:Courses/u:Course[u:Name='LIT103'])
|↑is
http://www.university.example.org/Universities/Capella/Courses.xml
which↑ is not equivalent to the URI in any alias. This means that it is 
an unresolved |↑SML↑ reference. 
 
--
ginny
 
From: public-sml-request@w3.org [mailto:public-sml-request@w3.org] On 
Behalf Of Sandy Gao
Sent: Thursday, November 15, 2007 11:50 AM
To: public-sml@w3.org
Subject: SMLIF inter-document reference proposal




Sorry for taking this long to have this ready. 

Thanks,
Sandy Gao
XML Technologies, IBM Canada
Editor, W3C XML Schema WG
Member, W3C SML WG
(1-905) 413-3255 T/L 313-3255