This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
We have to decide if users can add their own attributes and elements inside a documentRules (and its elements). Some may want to provide extra data for their tools to use. If we decide to allow this the DTD/schemes need to allow it.
> We don't need to do any more work to make > it easy; and we can't stop it. The only issue > is whether we encourage it. > Is there a concrete example? > -- > Sebastian Rahtz Wouldn't we have to explicitely allow non-ITS attributes and/or elements in the schemas to allow this? As for an example: one may be people adding constraints information or content type information, or other things not included in ITS. For instance: <its:documentRules xmlns:its="http://www.w3.org/2005/11/its" xmlns:ext="myITSExtension"> <its:translateRule its:translate="yes" its:selector="//*/@alt" /> <ext:MaxLengthRule ext:MaxLength="16" ext:Selector="//ledString" /> <ext:MachineTransRule ext:AllowUse="never" ext:Selector="//term | //quote" /> </its:documentRules> On external documentRules it's not so important because you can easily do the reverse (include ITS info in your own format). But it's potentially important for documentRules inside document instances as some host formats would allow ITS formally, and therefore allow extensions to be "validly piggy-backed" through ITS. [Not sure if it's always a good thing though] Maybe we could limit where the extensions would be allowed, like: no attributes, but allow elements (?), or even restrict even further by offering an extension element that allows attributes, and nothing else. (?) ...just thinking... -yves
This issue (Bug #3000) is one of the topic for discussion this week (and decision at the Wed Mar-29 teleconference). Summary: We have decided (during the Sophia face-to-face I think) to address extensibility in ITS by simply letting users use their own namespaces. The question here is: - Do we need to have "extension points" (place where attributes and/or element of non-ITS namepsace are allowed) formally specified in our schemas? (so one can validate ITS markup). - And if so, where in <its:documentRules> and its children these extension points should be? -yves
(In reply to comment #1) > > We don't need to do any more work to make > > it easy; and we can't stop it. The only issue > > is whether we encourage it. > > Is there a concrete example? > > -- > > Sebastian Rahtz > > > Wouldn't we have to explicitely allow non-ITS attributes and/or elements in the > schemas to allow this? > > As for an example: one may be people adding constraints information or content > type information, or other things not included in ITS. For instance: > > <its:documentRules xmlns:its="http://www.w3.org/2005/11/its" > xmlns:ext="myITSExtension"> > <its:translateRule its:translate="yes" its:selector="//*/@alt" /> > <ext:MaxLengthRule ext:MaxLength="16" > ext:Selector="//ledString" /> > <ext:MachineTransRule ext:AllowUse="never" > ext:Selector="//term | //quote" /> > </its:documentRules> > > On external documentRules it's not so important because you can easily do the > reverse (include ITS info in your own format). But it's potentially important > for documentRules inside document instances as some host formats would allow > ITS formally, and therefore allow extensions to be "validly piggy-backed" > through ITS. [Not sure if it's always a good thing though] > > Maybe we could limit where the extensions would be allowed, like: no > attributes, but allow elements (?), or even restrict even further by offering > an extension element that allows attributes, and nothing else. (?) ...just > thinking... > > -yves > (In reply to comment #2) > This issue (Bug #3000) is one of the topic for discussion this week (and > decision at the Wed Mar-29 teleconference). > > Summary: > > We have decided (during the Sophia face-to-face I think) to address > extensibility in ITS by simply letting users use their own namespaces. The > question here is: > > - Do we need to have "extension points" (place where attributes and/or element > of non-ITS namepsace are allowed) formally specified in our schemas? (so one > can validate ITS markup). > > - And if so, where in <its:documentRules> and its children these extension > points should be? my impression is that people might want to have extensibility to extend specific functionality of ITS: - the selection mechanism, realized with its:select - the values which are assigned e.g. via its:translate or its:dir - the passThrough mechanism, realized with xxxAttributes - the "same-as" mechanism (if we want it) I am wondering if we should allow a child element for all rules element, which separates this functionality, e.g. <its:translateRule its:select="//p" its:translate="yes"> <its:extension target="its:select">...</its:extension> <its:extension target="its:translate">...</its:extension> <its:extension target="its:xxxPassThrough">...</its:extension> </its:translateRule> The content of the element would be undefined. Locally, I would say we don't need to provide extensibility. > > -yves >
I wouldn't be in favor of creating additional elements for extension. Simply allowing non-ITS elements and attributes at certain levels should be enough. For example I would allow non-ITS attributes in each <its:zzzRule> element, and non-ITS elements in <its:documentRules>. And that would be it. How the extensions interact with ITS is the problem of the implementers of the extensions. It seems simpler that way. -ys
(In reply to comment #4) > I wouldn't be in favor of creating additional elements for extension. Simply > allowing non-ITS elements and attributes at certain levels should be enough. > > For example I would allow non-ITS attributes in each <its:zzzRule> element, and > non-ITS elements in <its:documentRules>. And that would be it. How the > extensions interact with ITS is the problem of the implementers of the > extensions. > > It seems simpler that way. > -ys > The question is whether we want to specify what can be extended, e.g. the selection mechanism, the values etc. If we don't want to specify it, we don't need additional elements, and I would take back my proposal. So the question is: Do we want to specify what is being extended?
I understood yesterday's discussion as follows: We only cover extensibility in the sense that we make sure that the ITS schema allows people to add stuff from their own namespace to 'rule'. We do not address questions like the values for 'dir' might be extended by ... Best regards, Christian
(In reply to comment #6) > I understood yesterday's discussion as follows: > > We only cover extensibility in the sense that we make sure that the ITS schema > allows people to add stuff from their own namespace to 'rule'. > > We do not address questions like the values for 'dir' might be extended by ... > > Best regards, > Christian > If that is the consensus of everybody, we can close this issue by saying: the documentRules element and all elements of the ITS namespace contained in it MAY contain elements or attributes from other namespaces, which are used for extending the functionality of ITS. I would not say s.t. about which points for extension we encourage (e.g. elements or attributes), except "within the data category specific rules". But as Sebastian said: we can't stop it anyway. Also as he said: I am wondering about examples.
My understanding is the same as Christian. Except that I would allow to add stuff to <documentRules> as well. But don't we still have to explicitely allow this in the schema if we want to be able to validate ITS elements? (at least with XML Schema (using ##any, ##other, etc.), I don't know about RELAX NG) For an example of extensions, here is one based on the input the Fujixerox people gave you Felix: <its:documentRules xmlns:its="http://www.w3.org/2005/11/its" xmlns:ext="myITSExtension"> <its:translateRule its:translate="yes" its:selector="//@p[class='ml']" ext:targetLanguages="en fr de" /> <ext:MaxLengthRule ext:MaxLength="16" ext:Selector="//ledString" /> </its:documentRules>
(In reply to comment #8) > My understanding is the same as Christian. o.k., so let's drop my proposal on "functionality specific" extensions. > Except that I would allow to add > stuff to <documentRules> as well. As Sebastian said, we can't prevent it anyway :) > > But don't we still have to explicitely allow this in the schema if we want to > be able to validate ITS elements? (at least with XML Schema (using ##any, > ##other, etc.), I don't know about RELAX NG) The generated schemas in the tagset draft are *not* normative. Both the conformance sections on schema conformance http://www.w3.org/International/its/itstagset/itstagset.html#conformance-product-schema and on processing expecations http://www.w3.org/International/its/itstagset/itstagset.html#conformance-product-processing-expectations don't talk about the generated schemas. That is: everybody is free to change them, or not to use them at all. > > For an example of extensions, here is one based on the input the Fujixerox > people gave you Felix: > > <its:documentRules xmlns:its="http://www.w3.org/2005/11/its" > xmlns:ext="myITSExtension"> > <its:translateRule its:translate="yes" its:selector="//@p[class='ml']" > ext:targetLanguages="en fr de" /> > <ext:MaxLengthRule ext:MaxLength="16" > ext:Selector="//ledString" /> > </its:documentRules> > Do you think we should have such an example in the spec?
> The generated schemas in the tagset draft are > *not* normative. Both the conformance sections on > schema conformance [...] and on processing expecations > [...] don't talk about the generated schemas. That is: > everybody is free to change them, or not to use them at > all. OK. But I still think we should generate non-normative schemas that can be used out of the box to allow extensions [if it's not too much work/change to do that]. Most users will use the schemas as they are. > ... > Do you think we should have such an example in the spec? I don't think it's needed. The paragraph about extension in section 1.3 seems enough. -ys
(In reply to comment #10) > > The generated schemas in the tagset draft are > > *not* normative. Both the conformance sections on > > schema conformance [...] and on processing expecations > > [...] don't talk about the generated schemas. That is: > > everybody is free to change them, or not to use them at > > all. > > OK. But I still think we should generate non-normative schemas that can be used > out of the box to allow extensions [if it's not too much work/change to do > that]. Most users will use the schemas as they are. The problem is: what to do with DTDs? I have created a schema which has "entry points" for any elements and attributes in the <documentRules> element, and the same for the <translateRule> element (here just as an example). Is that what you are thinking of? If "yes", I'd work with Sebastian on how to implement this in ODD. <?xml version="1.0" encoding="UTF-8"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:its="http://www.w3.org/2005/11/its" targetNamespace="http://www.w3.org/2005/11/its" elementFormDefault="qualified"> <xs:element name="documentRules"> <xs:complexType> <xs:choice maxOccurs="unbounded"> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:any namespace="##other"/> </xs:sequence> <xs:element ref="its:translateRule"/> </xs:choice> <xs:anyAttribute namespace="##any" processContents="skip"/> </xs:complexType> </xs:element> <xs:element name="translateRule"> <xs:complexType> <xs:sequence minOccurs="0" maxOccurs="unbounded"> <xs:any namespace="##other"/> </xs:sequence> <xs:anyAttribute namespace="##any"/> </xs:complexType> </xs:element> </xs:schema> > > > ... > > Do you think we should have such an example in the spec? > > I don't think it's needed. The paragraph about extension in section 1.3 seems > enough. o.k.
From my understanding, we needed provisions for allowing non-ITS namespace markup in the non-normative schemas. We seem to have/get this once Sebastian has passed some ODD-related info to Felix. What remains to be done wrt. the extensibility issue is the following: 0. advice people against working with extensions for which ITS capabilities exist; example: If your vocabulary captures translatability information with an attribute "myVoc:TranslateMe='y'" than use the ITS mapping/passthrough capabilities rather than working with an extension "myVoc:Translate='y'" 1. make sure that the spec. mentions that ITS does not provide ITS-specific extensibility (and rather relies on standard XML-namespace based mechanisms) 2. mention that the non-normative schemas are designed for use with standard (that is XML-namespace based) mechanism Best regards, Christian
(In reply to comment #12) > From my understanding, we needed provisions for allowing non-ITS namespace > markup in the non-normative schemas. We seem to have/get this once Sebastian > has passed some ODD-related info to Felix. > > What remains to be done wrt. the extensibility issue is the following: > > 0. advice people against working with extensions for which ITS capabilities > exist; example: If your vocabulary captures translatability information with an > attribute "myVoc:TranslateMe='y'" than use the ITS mapping/passthrough > capabilities rather than working with an extension "myVoc:Translate='y'" > > 1. make sure that the spec. mentions that ITS does not provide ITS-specific > extensibility (and rather relies on standard XML-namespace based mechanisms) > 2. mention that the non-normative schemas are designed for use with standard > (that is XML-namespace based) mechanism > > Best regards, > Christian > looks all fine to me. A question to Sebastian: Is it possible and necessary to generate a schema like above out of ODD? A question to all: would it be enough to show such an example schema just as an example? It is not normative anyway, see http://www.w3.org/Bugs/Public/show_bug.cgi?id=2924#c3
It would be easy enough in the ODD to specify as a part of a content model eg <zeroOrMore> <attribute> <anyName/> <text/> </attribute> </zeroOrMore> which would allow any attribute in any namespace. but that throws some chances of validation out the window, as it would also means that 'tarnslate="yes"' was valid. Personally, I think explicit allowance for anything seems like bad design. We're trying to predict things which by definition we cannot predict, at the cost of schema which which will be very loose in Relax and W3C, and impossible in DTD.
(In reply to comment #14) > It would be easy enough in the ODD to specify as a part of > a content model eg > <zeroOrMore> > <attribute> > <anyName/> > <text/> > </attribute> > </zeroOrMore> > which would allow any attribute in any namespace. but that > throws some chances of validation out the window, as it would also > means that 'tarnslate="yes"' was valid. > > Personally, I think explicit allowance for anything seems like > bad design. We're trying to predict things which by definition > we cannot predict, at the cost of schema which which will > be very loose in Relax and W3C, and impossible in DTD. I agree. At http://www.w3.org/Bugs/Public/show_bug.cgi?id=3000#c10 Yves said, he wants "out of the box" schemas for ITS. The example I created at http://www.w3.org/Bugs/Public/show_bug.cgi?id=3000#c11 is such an out of the box schema, with all disadvantages Sebastian mentioned: no predicatbility and cost of loose schemas. You can't have both a loose schema and schema which is good for validation. I would go for the later, hence: change nothing and just tell people that they can use namespace for extensions (what we already do).
(In reply to comment #14) > It would be easy enough in the ODD to specify as a part of > a content model eg > <zeroOrMore> > <attribute> > <anyName/> > <text/> > </attribute> > </zeroOrMore> > which would allow any attribute in any namespace. but that > throws some chances of validation out the window, as it would also > means that 'tarnslate="yes"' was valid. > > Personally, I think explicit allowance for anything seems like > bad design. We're trying to predict things which by definition > we cannot predict, at the cost of schema which which will > be very loose in Relax and W3C, and impossible in DTD. > I agree wuth Sebastian.
Resolution: No specific provision for namespace is to be made in the schemas. users will change the schemas as they need. The section 1.4 "Important Design Principles" includes a sub-section "No dedicated extensibility" addressing extensibility.
Closed, no further action necessary.