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

Upon re-reading, it may well be that the enclosed is actually the correct 
one for its stated purpose of capturing past discussion.  In the strict 
service of that goal, I cannot have any opinion since I was not on the 
4/24 call.  Given that, I may also be reasonably qualified to project the 
reaction of someone not there to the proposed summary.
My goal is not to capture that discussion; it is to give someone outside 
the group enough insight into the discussions to allow them to decide if 
their position was considered adequately to assess its potential, making 
the group's decision more understandable in light of the trade-offs 
involved.  I was (and still am) not comfortable that putting this (and 
only this) into the bug will or would give someone outside the group new 
information sufficient to feel fully heard and/or alter their opinions.
1.  targets are elements
The proposed answer would likely sound like circular reasoning.  I think 
the bug is challenging the wisdom of certain assumptions, but the answer 
starts from the current assumptions.
I think the point being made was subtly different: namely, that one could 
define target required in a way that would remove the necessity for one to 
descend into the document inherent in the current definition.  E.g., 
target required could be defined to be satisfied (for non-XML media types) 
if a document is retrievable, and (for XML media types) as it is today. 
Essentially, it means (as I see it) that "target" is defined somewhat 
differently based on the class of media types its document belongs to. One 
could position the "document exists" version as the more general, and the 
"element exists, is unique, etc" as the XML-specific, version of a single 
concept.  The effect of fragment components on the definition of "target" 
for non-XML media types is likely something SML would leave open for other 
specs.
One real down-side of this approach is the complexity it introduces for 
those concerned only with XML-based models.  A second (admittedly weaker) 
con is that the current working group members do not have much expertise 
in this area.
2. constraints are an ecosystem
The proposed answer (I would summarize as "consistency!") would be 
unlikely to persuade me. 
It is somewhat akin to the discussions we had on where to allow attachment 
of the various constraints.  Given the large asymmetries in how we 
resolved that, it's "curious" to see us using consistency as an argument 
here.  I expect the reader would simply say that defining the behavior for 
non-XML targets is wholly within the SML working group's power.
Same down-side as #1.
3. multiple personality deref() 
This seems a lot like #1.  If one posits changing the assumption that all 
targets are XML document elements, replying "things break" is not adding 
anything new.
The proposal I "heard" was that the definitions, including those for 
constraints, be made sensitive to media type (at least in the sense of 
"it's XML" vs "it's not XML", i.e. 2 classes of document).  It's not clear 
to me if others were "hearing" something else from what is here.  I don't 
grasp the reason one would (or would need to) make deref() behave 
differently for TR or how that helps.
4. there is no XPath for non-XML
This seems a lot like #3.
I think it would be fair to note that, _because_ of the absence of XPath, 
a number of SML facilities are unusable (in the sense of  "we don't know 
how, and SML is unlikely to define how") for non-XML media types... 
anything in fact that requires content w/in the document, including all 
those you list.
What's left (target required + ?) may or may not be an interesting set.
So is the complexity of bifurcating all of two specs worth allowing target 
required checking for XHTML?  Or would a more economical solution, and 
perhaps one better suited to the wider HTML (sic - no X) space be to 
define an analog for target required of (hypertext) links?
5. "It changes a basic assumption, and that has costs"
For my money, this is a potentially persuasive item.  A list of the 
necessary hits and the cost/benefit would correspond directly to the 
degree of persuasiveness.  A reasonably complete list might be reasonably 
persuasive.  The preceding 4 points seem like a good start.

Since I was not at the discussion, I also wonder (seeing no evidence in 
the minutes) whether or not (assuming I heard the commenter's intent 
correctly) we did the same analysis in reverse.  If one proceeds from the 
assumption that SML and its definitions is "media type centric" rather 
than "XML document centric", what side effects and unpleasant implications 
does _that_ lead to? 
I've never seen media type used out side of a MIME context - does it have 
any meaning for "born binary" components, documents retrieved over other 
protocols, and so on?  RFC 4288 says media types for use in MIME and other 
Internet protocols  2616 confirms it is used in HTTP.  "Born binary" would 
seem to be an obvious question left here.  What would be the impact to 
current SML implementations?

Best Regards, John

Street address: 2455 South Road, P328 Poughkeepsie, NY USA 12601
Voice: 1+845-435-9470      Fax: 1+845-432-9787



From:
Kumar Pandit <kumarp@windows.microsoft.com>
To:
"public-sml@w3.org" <public-sml@w3.org>
Cc:
Kumar Pandit <kumarp@windows.microsoft.com>
Date:
04/30/2008 08:42 PM
Subject:
discussion on : 5544 Why does SML require that the target of SMLURI  be an 
XML element?



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.