Just trying to make the type explicit both in documentation and schema, same as elsewhere, we always mention NMTOKEN in the value descriptions if the type is NMTOKEN The xsd validation will be NMTOKEN, while the advanced validation should be against an array of NMTOKEN strings that contains only names of XLIFF (core?) elements Rgds dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734
http://www.cngl.ie/profile/?i=452 mailto:
david.filip@ul.ie On Fri, Mar 14, 2014 at 2:06 PM, Yves Savourel <
ysavourel@enlaso.com > wrote: I would propose to drop ‘NMTOKEN’ from your proposed changed. (no need to get to get overly technical) The new text would be: Value description: Name of any valid XLIFF element which is a sibling, or a child of a sibling element, to the change track module within the scope of the enclosing element. From: Dr. David Filip [mailto:
David.Filip@ul.ie ] Sent: Friday, March 14, 2014 7:55 AM To: Yves Savourel Cc:
xliff@lists.oasis-open.org Subject: Re: [xliff] Discussion re csprd03 209 Yves, thanks for pointing to Tom's CFD, the solution seems OK with me. I can se that the ctr module now references its own appliesTo. I would just make a minor change in its value description OLD: Value description: Any valid XLIFF element which is a sibling, or a child of a sibling element, to the change track module within the scope of the enclosing element. NEW: Value description: NMTOKEN name of any valid XLIFF element which is a sibling, or a child of a sibling element, to the change track module within the scope of the enclosing element. How does that sound. The value cannot obviously be the element itself, so this seems an obvious editorial clarification Cheers dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734
http://www.cngl.ie/profile/?i=452 mailto:
david.filip@ul.ie On Fri, Mar 14, 2014 at 1:45 PM, Yves Savourel <
ysavourel@enlaso.com > wrote: Hi David, From the schema viewpoint Tom sent this:
https://lists.oasis-open.org/archives/xliff/201402/msg00037.html As for what value to use: I guess the element names would be fine. Not sure if it's wise to have a list. For my concern about the case of deletion. I think I was reading too much into the definition, thinking the element *had to exist* to be a valid value. But the text can be interpreted also as an element *could* be there. So, Tom's fix looks enough for me. -yves From:
xliff@lists.oasis-open.org [mailto:
xliff@lists.oasis-open.org ] On Behalf Of Dr. David Filip Sent: Friday, March 14, 2014 7:23 AM To:
xliff@lists.oasis-open.org Subject: [xliff] Discussion re csprd03 209 Yves, Tom, all I just realized that I co-own this issue. [Sorry I was filtering DavidF only so I missed this one that says David..] AFAIK change track inconsistently re-uses the core appliesTo. As of now I haven't formed an opinion how to best fix that with minimum impact. @Tom, did you make any schema changes to alleviate that so far? @Yves, any suggestions how to best fix that with minimum impact? Will look into it in more detail shortly, but any more input appreciated Thanks and regards dF Dr. David Filip ======================= LRC CNGL LT-Web CSIS University of Limerick, Ireland telephone: +353-6120-2781 cellphone: +353-86-0222-158 facsimile: +353-6120-2734
http://www.cngl.ie/profile/?i=452 mailto:
david.filip@ul.ie --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php