- From: <Patrick.Stickler@nokia.com>
- Date: Tue, 19 Aug 2003 09:59:56 +0300
- To: <duerst@w3.org>, <jjc@hpl.hp.com>, <w3c-i18n-ig@w3.org>, <w3c-rdfcore-wg@w3.org>
- Cc: <swick@w3.org>, <timbl@w3.org>, <sandro@w3.org>, <djweitzner@w3.org>
> -----Original Message----- > From: ext Martin Duerst [mailto:duerst@w3.org] > >No XHTML specific solution is required. > > > >I've already pointed out XML Fragment > > I just have looked at the XML Fragment spec. Let's for > a moment assume that XML Fragment is a full REC. There are > several issues that make it difficult to see how this could > be used to address the actual problems we are working on. I never said it fully solved the problem. Only that it represented a promising approach to solving this problem, and that I18N could work towards seeing either it, or something like it, brought to maturity in the XML community (rather than pushing RDF Core to provide a *proprietary* and *partial* solution at the likely expense of RDF users). > >I've also pointed out that it is not RDF's duty to > >solve the general XML Fragment context issues. > > I have agreed with that. RDF only has to solve these > issues as far as RDF is concerned. Insofar as these are not RDF issues, RDF has nothing further to solve. You're insistence that RDF make XML-specific issues its own just because it uses XML to serialize its abstract graphy syntax, is simply unjustifiable. What you are proposing, that each individual formalism that might happen to encapsulate XML *fragments*, would introduce a proprietary, limited solution to a general XML problem, really amazes me. Having a plethora of different approaches to expressing contextual knowledge relevant to the consumption of XML fragments seems completely at odds with your often expressed desire for consistent treatment for the sake of users. It will result in XML users having to juggle numerous different "local" solutions to a general problem. Your insistence that RDF address this general problem simply strikes me as counterproductive and in the long term detrimental to the XML community. In short, having RDF, or any specific formalism, address general XML issues, rather than define a promote a general XML solution that can be transparently employed with all such formalisms, is bad policy. And if such a proprietary, local solution might weaken the value and utility of the specific formalism, then such a position is even less defensible. > RDF makes some very > explicit decisions (it cannot avoid making these decisions). > And it explicitly decides that some stuff is inherited, > in particular: > - 'visibly utilized' namespace declarations These are syntactic issues relating to the XML serialization, not semantic issues that impact the interpretation of the graph. Because element and attribute names cannot be full URIs, RDF serializers *must* use qnames and *must* define XML namespace prefixes when serializing RDF graphs. In order to avoid grossly obese XML serializations (even more than usual ;-) these namespace prefix declarations can be distilled to the root level (or whatever level is most appropriate). The same is true for xml:base. Interning relevant namespace prefix definitions in canonicalized XML fragments is just mucking about with syntax. It is not affecting the semantics of the graph. Applying xml:lang to XML fragments, or to any typed literal, is a completely different story. > - xml:lang for plain literals I consider this to be a bug, or at best a quirk, but one that for legacy reasons cannot be corrected at this time. Unlike XML literals, deployed systems and content precluded any change to this treatment. As you suggested earlier, recognition of a shortcoming in some part of a standard does not constitute approval as a general practice. My hope is that general practice will shift away from the use of xml:lang for language qualification of plain literals, in favor of more generic forms of expression which are more transparent to reasoners, and that some subsequent version of the spec can finally deprecate this feature. But for now, it is what it is due to M&S. > >I don't consider the XML scraping use case to > >identify any failure in the present (editors' > >draft) design. > > You don't. We do. Fair enough. Though I personally do not feel you have suceeded in demonstrating that your position is either technically or practically better than ours. And I don't see that anyone else is strongly convinced. Our position is based on substantial input from the RDF and OWL communities -- and further, maintains a clear and clean division between that which is specific to RDF and that which is specific to XML, which is the mark of sound engineering. I appreciate that language scoping of content is a very important issue, and one that is not optimally addressed by the various W3C standards, but I don't see how a proprietary RDF-specific solution will benefit the XML community in the long run. Again, seeking the proprietary treatment of this general XML problem is bad policy, insofar as the goals of the W3C are concerned, in having synergetic interoperability between its recommendations. > >It is a problem that will exist for *any* case where > >an XML Fragment is taken out of its context and > >encapsulated in *any* formalism. > > > >Any solution that RDF might offer to this problem will > >be an RDF-specific solution. And such a solution will > >be a partial solution, limited only to language > >context, insofar as the general problem of capturing > >XML Fragment context is concerned. > > I18N is interested in language context. XML 1.0 defines > how xml:lang is working. This is different from DTD-specific > stuff. RDF inherits language context for plain literals. > What RDF has in the post-lastcall draft is an RDF-specific > solution. It is a partial solution, and a solution that > is affecting I18N negatively. I'm sorry, but this has been addressed numerous times before, and it's tiresome that you continue to return to this. RDF/XML is not intended to be consumed as XML. The RDF/XML is just an expression of the graph, and all that matters is what is in the graph. RDF is free to say how that XML is interpreted and what is mapped to the RDF graph. We *START* with the graph, and specify what can be expressed in the graph, and then use XML to serialize the *graph*. Anything that is in the XML which does not correspond to some form of expression in the RDF graph is *IRRELEVANT* to the meaning of the content. That includes xml:lang, no matter what the XML specs say. Your insistence on forcing interpretatation of the serialized graph in terms of the XML specs has been as the root of this longrunning debate. You keep pushing the X-view. RDF is based on the G-view. > >Far better for the I18N WG to work with the **XML** > >community on a general, consistent solution to this > >problem using XML Fragment, or similar, > > I probably said this earlier, but if the RDF Core WG > had asked the I18N WG for help on this issue at the > Technical Plenary in Cannes, I'm quite sure we would > have helped you. (I don't think it would have been > only the I18N WGs job to do that.) The RDF Core WG > asked the I18N WG about blocking off language information > when inserting XML fragments into a larger document, > and I18N made sure that you got the solution > (xml:lang=''). If you now think that you found out > that you looked for the wrong thing, please don't > blame us. 1. The discussions in Cannes were concerning typed literals in general, specifically those such as XML Schema simple types, and XML literals at that time were not even in the scope of those discussions because at that time, XML literals were not typed literals. Consideration of a mechanism such as xml:lang="" was based on a design which allowed for the optional presence of lang tags for typed literals, a design which was later rejected by the WG, being rife with problems. 2. I do not see how the RDF Core WG was in any way bound to any specific solution based on discussions with I18N about such problems, and the introduction of a mechanism such as xml:lang="", while remaining useful for XML users in general (and justifyable for XML use on its own merits) is not a manditory component of any solution chosen by the RDF Core WG. And, the mechanism *still* remains valid and useful for blocking the language qualification of plain literals (RDF being stuck with that design) and continues to be of benefit, as intended, for RDF users. It simply does not apply to typed literals, including XML literals, since language tags are not part of the expression of typed literals in the graph. > >than to continue > >to harass the RDF Core WG to provide a proprietary > >solution that will likely be *INCOMPATIBLE* with > >any general solution that might later arise within > >the XML community. > > Sorry, but the I18N WG and the RDF Core WG amicably > agreed to a solution in Cannes. Nothing in the present solution invalidates or devalues the xml:lang="" mechanism that arose out of the Cannes discussions. The omission of lang tags from XML literals, as for all other typed literals, does not remove the need for the xml:lang="" mechanism, either for RDF users or for XML users in general. Your (seeming) assertion that the recent change in the treatment of XML literals has either wasted the I18N's time and/or constitutes some sort of "breach of contract" with the I18N is IMO unjustified. > The RDF Core WG up > to last call didn't see any problem with this > solution. That is simply false. Even a cursory review of the WG discussion list traffic will bear that out. In truth, there was *alot* of concern in the WG about the odd design -- treating XML literals differently from other typed literals. The fact that the RDF community responded strongly against it during last call led to the *correction* of the design. > And as explained above, RDF has to make > some decisions, and does make some. Quite so. And there appears very strong concensus in the RDF Core WG that we have indeed made the *right* decisions. > > >-- > > > >Here is the last I personally plan to say on this matter: Oh well..... ;-) > >I've seen two key issues that you have brought to our attention: > > > >1. XML literals don't have a lang tag indicating > > language scope, so how do XML users capture > > this contextual information about fragments. > > > >2. The relationship between plain literals and > > XML literals without markup has not be addressed. > > > >As for #1, I've said enough, I think, above about that. > >The context of an XML Fragment is not RDF's concern. And > >there exists a W3C rec (albeit only CR) for addressing > >such issues in a consistent manner. It is up to the > >XML community to bring it to maturity and promote its use. > >RDF should remain agnostic as to such solutions, supporting > >whatever the XML community decides (which it will do, > >without any need for modification, based on the latest > >editors' draft). > > See above. The XML Fragments CR doesn't cover the use case > you are thinking about. And RDF isn't agnostic, it currently > makes some choices, and it always did. And again, I never claimed it was perfect for the task and would not need tweaking to address such needs. But it does, however, constitute a *substantial* amount of completed work exploring the issue of XML fragments, and would be a likely foundation for a general solution. The point is that the solution should be a general XML solution, along the lines of XML Fragment, and not something specific to RDF -- but rather supported by RDF transparently. > >As for #2, the editors are working on text to clarify this > >relationship. In a nutshell "abc" and > >"abc"^^rdf:XMLLiteral denote two distinct values, > >but applications may choose to "convert" or "coerce" > >between such values, without (substantial) loss of > >meaning, just as they may convert between > >"1"^^xsd:integer and "1.0"^^xsd:decimal. As far > >as the MT is concerned, however, plain literals values > >and XML literal values are disjunct. > > With the exception of the question of how language information > is handled, this is okay as far as we are concerned. Glad to hear it. I am, myself, then satisfied that we have addressed all of the I18N concerns to the degree that can and should be done, per the principles of sound engineering, clean layering, and modular design. Patrick -- Patrick Stickler Nokia, Finland patrick.stickler@nokia.com
Received on Tuesday, 19 August 2003 03:00:05 UTC