Re: locInfo

Hi Yves,

On Fri, 27 Jan 2006 13:28:52 +0900, Yves Savourel <yves@opentag.com> wrote:

>
>>> - locInfoType is defined as xs:token in the XSD for ITS, but
>>> as CDATA in the DTD. Shouldn't we enumerate the values in the
>>> DTD?
>>
>> That would be a possibiliyt. We discussed at some point to have
>> two attributes instead of one: "@locInfoDesc" and "@lofInfoAlert".
>> In that way, we would not need "type". What do you think?
>
> Mmmm... I think it complicate things too much.
>
>
>>> - If locInfoType is not present, do we have a default value
>>> for it? If so, is it description or alert?
>>
>> The solution with two attributes would solve that problem
>
> Really? I would guess that we would allow either @locInfoDesc or  
> @lofInfoAlert, or both. But to allow either one, we need to make
> each ome optional, which means we could end up with nothing...

currently all datacategory and selector attributes are optional, so a mean  
user can do a lot of useless things like <its:documentRule  
translateSelector="//p"/>. We could define a schematron definition which  
can be used in addition to the ITS datacategories, to make additional  
checks, like

<schema xmlns="http://purl.oclc.org/dsdl/schematron">
  <title>A Schematron Mini-Schema for Schematron</title>
  <ns prefix="sch" uri="http://purl.oclc.org/dsdl/schematron">
  <pattern>
    <rule context="*[its:translateSelector]">
      <assert test="@translate">A @translateSelector attribute has to be  
accompaigned by a @its:translate attribute</assert>
...</schema>

> Maybe having a default "description" value for locInfoType would
> besimpler?

the problem is that you don't have default values in XML Schema or RELAX  
NG :( . To avoid the problem, we could write in the prose description of  
the data category that a user of the data category MUST use the  
@locInfoType attribute.

>
>
>>> ...I can see the inheritence interest in some case (for non-inline
>>> elements), but if the ITS processor uses some "tree-decoration"
>>> method to propagate the note, this can end up in a huge amount of
>>> extra nodes not really necessary. Mmmm... I guess it's a processor
>>> problem...
>> Did you see what I wrote at
>> http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0051.html
>> about the inheritance problem with @locInfo? The general question is:
>> how to handle inheritance if we don't have *alternative* values,
>> that is s.t. different from its:translate, its:dir etc.
>> We *could* leave that to the implemenation, which could decide if
>> inheritance should be turned of or not. We could also add a new
>> feature to ITS, e.g. an @inheritance attribute with values "yes"
>> or "no". I'm not sure what is more feasible.
>
> Your example is a good one: should the inheritance for locInfo add or  
> override?
> But it seems I'm talking about something slighly different: I'm not sure  
> if inheritance (regardless what it does makes sense in many
> cases for locInfo).

yes, maybe I did not get your point. Maybe other people know?

Cheers,
Felix

>
> I think we will have to come up with some processing expectation or the  
> implementations (and therefore the markup in the documents
> will differ too much).
>
> Cheers,
> -yves

Received on Friday, 27 January 2006 06:39:21 UTC