RE: JJC's take on I18N concerns

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