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

[Bug 2620] Necessity of dislocated scope / selectors *and* insitu scope / selectors

From: <bugzilla@wiggum.w3.org>
Date: Sun, 08 Jan 2006 04:49:22 +0000
To: public-i18n-its@w3.org
Cc:
Message-Id: <E1EvSUc-00044p-SF@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=2620





------- Additional Comments From fsasaki@w3.org  2006-01-08 04:49 -------
(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'.
Received on Sunday, 8 January 2006 04:49:54 UTC

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