[Fwd: Re: Summary of strings, markup, and language tagging in RDF (resend)]

Somehow, I accidentally dropped rdf core off the distribution list for
this.

Brian
-----Forwarded Message-----

From: Brian McBride <bwm@hplb.hpl.hp.com>
To: Martin Duerst <duerst@w3.org>
Cc: Graham Klyne <gk@ninebynine.org>, Dan Connolly <connolly@w3.org>, w3c-i18n-ig@w3.org, Ralph R. Swick <swick@w3.org>
Subject: Re: Summary of strings, markup, and language tagging in RDF    (resend)
Date: 03 Jul 2003 11:50:35 +0100

[I've dropped Misha and timbl from the dist list - feel free to forward
this/reintroduce them if you feel it is appropriate]

Martin,

Thank you.  I found this message very helpful.  I realise you have made
these points before, and whilst repeating yourself is burden on you, I
found that collecting these points together helped clarify things in my
mind at least, considerably.

So, if I can try to summarize (at least my understanding) of the details
you gave (I've included some detailed comments amongst your text below,
but they are not greatly relevant, I think).

  - users familar with XML will be surprised that the lang tag does not
affect an xml literal
  - users will be confused that plain literals are treated differently
from XML literals
  - the common case is that the user wishes an enclosing lang tag to
apply to an xml literal, so why burden the user with duplicating the
information
  - not all XML languages have neutral elements such as <span> that can
be added to hold extra type information
  - conversion from other XML languages to RDF/XML will require more
complex code

Now, here is an attempt to reconstruct a rationale for why RDFCore chose
the option it did.  I'm not writing this in any sense in a defensive
posture.  My view is that RDFCore simplified the handling of XML
Literals post last call and sought feedback from i18n whether it had
simplified too far.  I just want to get the arguments laid out so we can
all take an informed decision about that question. 

  - RDFCore had last call feedback, particularly from members of WEBONT
that the treatment of XML literals in the last call WD's was
unsatisfactory, particularly in the formal treatment, leading to a
desire for simplification and greater uniformity.  This is what led to
the post last call proposal.

  - RDFCore considered retaining the wrapper element, but decided not to
because it is more complicated for *implementors* (I note i18n's
arguments are more user centred)

  - It has been argued that there are cases where importation of the
lang tag is not desired, so why burden users with having to turn it off

Likely I need some help here to correct, clarify and complete.  RDFCore,
please chip in and I'll summarize again if necessary, afterwards.

I note that i18n arguments centre around a user writing RDF/XML by
hand.  I wonder whether some of the differences of view arise because
RDFCore expects RDF/XML to be largely written by machine.

Martin has rightly pointed out that there are several possible solutions
to the issue b), but I would like to be clear whether reintroducing the
wrapper element would be satisfactory.

Martin, in your opinion, would re-introducing the wrapper element and
having it carry any in scope lang tag address issue b) to i18n's
satisfaction?

A few minor comments interspersed below.

Brian

On Wed, 2003-07-02 at 16:50, Martin Duerst wrote:

[...]

> 
> How do you suggest we will ever be able to explain to users
> that one of the literals is the same in both cases, because
> xml:lang doesn't count for the XML Literal, but is different
> for the other case, because in that case, xml:lang counts?
> That just for the thing that the spec calls an XML Literal,
> the language inheritance rules of XML 1.0 are put out of force?

The explanation might be that parseType="Literal" indicates a standalone
fragment of XML embedded or quoted within the current document.  This
isn't strictly true in that a default namespace is carried in, but that
could be described as an exception.

XML isn't very good at embedding in itself - I think one of the reasons
we have this problem.

[...]

> - Adding an additional element is a change of the markup, it effectively
>    creates something different (see my answers to Pat for details)

True, but that's a feature not an argument.

> - It can get overly voluminous even if (almost) everything is in one
>    language.
Hmm, not convinced by that.

> - It makes adding language information very tedious even in the
>    simplest cases. 

"very"?  Thats value laden.  The objective fact is that it requires the
addition of one extra element where one needs to specify a language.

> It is definitely not so that adding language
>    information is the first thing that people creating data are
>    thinking about. If it gets too complicated, they will just
>    ignore it (might work out somehow) or they may do it in
>    a haphazard fashion (very bad).
> 
> 
> >Martin: is that the sum of your objection?  Can you provide better
> >examples that clearly indicate the force of your argument?
> 
> I hope I have done so above.

Thank you.  Excellent job.

[...]

> 
> One of the cons that some people have mentioned is that
> having language inherit may make it more difficult to
> integrate data from different sources.

I personally don't see that argument.  I assume that data integration
would be done on the RDF graph, not in the XML syntax, so that issue
just doesn't arise.

Brian

Received on Friday, 4 July 2003 06:30:47 UTC