- From: <bugzilla@wiggum.w3.org>
- Date: Sun, 08 Jan 2006 04:49:22 +0000
- To: public-i18n-its@w3.org
- Cc:
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