W3C home > Mailing lists > Public > public-i18n-its@w3.org > January to March 2006

Re: JLA OSDS seminor

From: Felix Sasaki <fsasaki@w3.org>
Date: Fri, 03 Feb 2006 21:48:22 +0900
To: "Hiroki Sato" <hrs@allbsd.org>
Cc: www-i18n-comments@w3.org, public-i18n-its@w3.org
Message-ID: <op.s4eduwynx1753t@ibm-60d333fc0ec>

Hi Hiroki,

On Fri, 03 Feb 2006 01:15:30 +0900, Hiroki Sato <hrs@allbsd.org> wrote:

> "Felix Sasaki" <fsasaki@w3.org> wrote
>   in <op.s39trvv9x1753t@ibm-60d333fc0ec.mag.keio.ac.jp>:
> fs> Hi Hiroki,
> fs>
> fs> Do you mind if I send your comments to the list  
> www-i18n-comments@w3.org?
> fs> This is the public list our working group is using for discussions on
> fs> working drafts. You can also post to that list directly, if you want.
>  No, I do not mind.  This (and your mail I quoted) is also sent to the
>  list, isn't it?


> fs> In our latest DTD version of the ITS schema, we make definitions  
> like the
> fs> one which I attach at the end of this mail. We are using many  
> parameter
> fs> entities. I think to add ITS attributes to an existing DTD, you only  
> need
> fs> to add the parameter entities att.datacats.attributes and
> fs> att.selector.attributes to each element of your schema. As for ITS
> fs> elements, you need to add the declaration of the documentRules  
> element to
> fs> your schema. What do you think: what problems could occur from this  
> design?
>  Hmm, I also think adding %att.datacats.attributes; and
>  %att.selector.attributes; to all of the existing elements is
>  the best option we can take for the ITS attrs.  What I was
>  concerned about was how easy this could be done in practice.
>  As you know, well-modularized DTDs such as xhtml-modularization
>  have parameter entities which can be used as useful knobs (such
>  as %Core.extra.attrib;) for merging, and the merging can
>  be done without modification to the existing DTD.
>  This means that we can create a new DTD with importing the
>  XHTML vocabulary without modification of XHTML DTD itself.
>  If the base DTD does not have such knobs, on the other hand,
>  we have to add the ITS attrs and elements into it directly.
>  In such a case, to me, difference between adding an ITS attr
>  to all of the elements and adding an ITS element to all of
>  the elements (as its child) is very small.
>  Simple search-and-insert may work, or it may be edited more carefully.
>  In either case, because of the separated namespace the negative
>  impact to the base DTD would not be severe, I think.

We decided in the group a while ago against the idea of child elements,  
see below.

>  Next, I have read its0505LimitImpact and am thinking the amount
>  of impact of adding elements from the perspective of compatibility  
> (with ITS
>  and without ITS).  It is true that some XPath expressions can make
>  different results, but I think it is due to one of the intrinsic
>  properties of markup.  Adding <emphasis> in <para> is bad and
>  <para emphasis="yes"> is good?  Thinking an ITS element as an  
> "interference"
>  is still arguable because adding meta-information to a certain range
>  of a document is fundamental role of an element.

you are right, but the motivation for our decision is grounded in one  
important task for us: we want to approach developers of widely used  
schemas like open document, DocBook, HTML, DITA etc. to deploy ITS. This  
task is much easier if we tell them "all you have to do is add ITS  
attributes to your schema and one element: its:documentRules". Many of  
these schemas have also standardized processing resources, e.g. XSLT  
stylesheets. Having lots of ITS elements would force people to change  
these stylesheets - which they surely don't want.

>  Well, my ideas do not take shape very much yet and I cannot point out
>  a specific problem, but impact to the base schema and ITS functionality
>  involve certain trade-off relationship, and I have a vague sense that
>  simply avoiding an element and preferring an attribute tend to limit
>  (or break) appropriate functionality...

you are right, that is a problem. We are trying to keep it regulary in  
mind ...

> fs> This is a very interesting proposal. I think it is somehow related  
> to the
> fs> requirement of identifying inline and subflow elements, see
> fs> http://people.w3.org/rishida/localizable-dtds/#inline-elements . We  
> are
> fs> currently working on this and would like to take your feedback into
> fs> account.
>  Thanks for the pointer.  I think I will read it.  I need to learn the
>  existing discussion first ;)

Great! I am very much looking forward to more feedback from you.


> --
> | Hiroki SATO
Received on Friday, 3 February 2006 12:48:38 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:43:06 UTC