This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 2620 - Necessity of dislocated scope / selectors *and* insitu scope / selectors
Summary: Necessity of dislocated scope / selectors *and* insitu scope / selectors
Status: CLOSED FIXED
Alias: None
Product: ITS
Classification: Unclassified
Component: ITS tagset (show other bugs)
Version: WorkingDraft
Hardware: PC Windows XP
: P2 normal
Target Milestone: PublicationFebruar20
Assignee: Felix Sasaki
QA Contact: ITS mailing-list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 2619 2621
  Show dependency treegraph
 
Reported: 2005-12-26 08:45 UTC by Felix Sasaki
Modified: 2006-07-21 17:47 UTC (History)
0 users

See Also:


Attachments

Description Felix Sasaki 2005-12-26 08:45:54 UTC
Comment from Francois Richard, only entered into bugzilla by Felix:

Currently, an ITS implementation has to decide whether it wants to use in situ
or dislocated scope / selectors. Would it be possible to use only dislocated
scope / selectors, and in situ only without selectors (but with a default scope
for each data category)? That would make the conflict resolution between in situ
and dislocated easier, and the overall design of ITS, without loosing expressive
power of selectors (since every in situ selector can be expressed dislocated as
well).
Comment 1 Christian Lieske 2006-01-05 10:47:17 UTC
Very good comment/idea which also occurred to me.

From my understanding, it could give rise to a set of data categories which is 
related to ITS itself. From my point of view, this set looks somewhat 
like 'elementFormDefault', 'attributeFormDefault' etc. in XSD.

To be specific: We could think about a data category like 'Selector Type' which 
for example could be coded as an attribute 'selectorType' with the possible 
values 'in-situ, dislocated, both, unknown'.
Comment 2 Felix Sasaki 2006-01-08 04:49:21 UTC
(In reply to comment #1)
> Very good comment/idea which also occurred to me.
> 
> From my understanding, it could give rise to a set of data categories which is 
> related to ITS itself. From my point of view, this set looks somewhat 
> like 'elementFormDefault', 'attributeFormDefault' etc. in XSD.
> 
> To be specific: We could think about a data category like 'Selector Type' which 
> for example could be coded as an attribute 'selectorType' with the possible 
> values 'in-situ, dislocated, both, unknown'.

I don't like the idea of putting a selection related aspect into the data
categories. And no matter if we call this "data category" or not: 'selector
type' makes possibly things complex. What should happen, if the type is
"in-situ", but there is dislocated ITS information in the document? I think the
initial idea of Francois's comment was to make things easier, not more complex.
I think this question is more one of conformance to ITS: does an implementation
support ITS information in a schema, and / or in situ and / or dislocated? If we
want to allow these variations, we could specify each of the three as an
optional implemenation feature, which would be the same effect as with the
attribute values 'in-situ, dislocated, both, unknown'. 
Comment 3 Felix Sasaki 2006-02-09 14:14:52 UTC
The working group decided to adopt this proposal. See
http://lists.w3.org/Archives/Public/public-i18n-its/2006JanMar/0098.html