OASIS XML Localisation Interchange File Format (XLIFF) TC

On 2.12.2014 10:48, Dr. David Filip wrote: > I guess one of the practical implications is: > If you have an attribute of the glossary namespace (we typically prefix it > as gls:, and I am using here typical prefixes as shorthand for their > namespaces) on an element that is from the glossary namespace - > Soroush and I would think that it actually does not matter if you prefix it > or not. If it is not prefixed it will be "magically" considered of the same > namespace (vocabulary?) as the element, on which it is and not the xlf: > namespace. But also that there is no harm in explicitly prefixing the > attribute. No, prefixed and unprefixed attributes are completely different and you have to decide which way to go. For elements, the following two documents are identical: <foo xmlns=" http://example.com"/ > <bar:foo xmlns:bar=" http://example.com"/ > When we add attributes, the following two documents are identical, note missing bar: prefix on attribute: <foo a="123" xmlns=" http://example.com"/ > <bar:foo a="123" xmlns:bar=" http://example.com"/ > And these two documents are completely different from both of: <foo bar:a="123" xmlns=" http://example.com" ; xmlns:bar=" http://example.com"/ > <bar:foo bar:a="123" xmlns:bar=" http://example.com"/ > > However, Yves previously said that it is invalid if you prefix an attribute > that is on an element from the SAME namespace. Could you point to the correct thread, so I can comment? I'm just remotely monitoring what's happening in XLIFF world? > What is the best practice? It depends, about which XLIFF feature we are talking about? -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML and Web consulting and training services DocBook/DITA customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. ------------------------------------------------------------------ Bringing you XML Prague conference http://xmlprague.cz ------------------------------------------------------------------ Attachment: signature.asc Description: OpenPGP digital signature

I have to say I am completely confused now. This is how a typical XLIFF document declares namespaces <?xml version="1.0" encoding="UTF-8"?> <xliff xmlns="urn:oasis:names:tc:xliff:document:2.0" xmlns:xmrk="urn:xmarker" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance " xmlns:fs="urn:oasis:names:tc:xliff:fs:2.0" xmlns:mtc="urn:oasis:names:tc:xliff:matches:2.0" xmlns:gls="urn:oasis:names:tc:xliff:glossary:2.0" xmlns:mda="urn:oasis:names:tc:xliff:metadata:2.0" xmlns:res="urn:oasis:names:tc:xliff:resourcedata:2.0" xmlns:ctr="urn:oasis:names:tc:xliff:changetracking:2.0" xmlns:slr="urn:oasis:names:tc:xliff:sizerestriction:2.0" xmlns:val="urn:oasis:names:tc:xliff:validation:2.0" xmlns:itsm="urn:oasis:names:tc:xliff:itsm:2.1" xmlns:xhtml=" http://www.w3.org/1999/xhtml " xmlns:svg=" http://www.w3.org/2000/svg " srcLang="en-us" version="2.0" trgLang="de"> <file id="f216"> <unit id="xmrk_000_concept"> <gls:glossary> <gls:glossEntry id="ge1"> <gls:term source="SnowTerms">snow</gls:term> <gls:translation id="t1" source="SnowTerms">Schnee</gls:translation> <gls:definition source="SnowTermsDefinitions">atmospheric water vapor frozen into ice crystals and falling in light white flakes or lying on the ground as a white layer.</gls:definition> </gls:glossEntry> <gls:glossEntry id="ge2"><!-- valid 5.2.4.3 contraint: A <glossEntry> element MUST contain a <translation> or a <definition> element to be valid. --> <gls:term>slushy</gls:term> <gls:definition source="SnowTermsDefinitions">Having qualities of partially melted snow or ice. </gls:definition> </gls:glossEntry> </gls:glossary> <segment id="xmrk_001_title"> <source xml:lang="en-us" xml:space="default">Skiing</source> <target xml:lang="de">Skiing</target> </segment> </unit> </file> </xliff> The above example only uses the gls module namespace apart from the core namespace that does not have a prefix declared in the example Do you say that in the above context 1) <gls:term source="mydictionary">slushy</gls:term> is different from 2) <gls:term gls:source="mydictionary">slushy</gls:term> ? My questions are  Is the "source" attribute in 1) in the gls: namespace?  Is 2) valid? Is the "source" attribute in 2) in the gls: namespace?  Doesn't 2)  mean the same as 1) ? Further 3) <gls:term source="mydictionary" itsm:person="John Doe">slushy</gls:term> Even if I do not prefix source, which is in the same namespace as "gls:term", I assume I have to prefix "person" in 3) to make sure that it belongs to the itsm: namespace and gets validated against the itsm: schema. Otherwise it would be assumed to belong to the same vocabulary as gls:term and fail to validate as there is no attribute "person" in the gls: namespace, correct? Thanks and cheers dF Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer  LRC CNGL 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 Tue, Dec 2, 2014 at 10:52 AM, Jirka Kosek < jirka@kosek.cz > wrote: On 2.12.2014 10:48, Dr. David Filip wrote: > I guess one of the practical implications is: > If you have an attribute of the glossary namespace (we typically prefix it > as gls:, and I am using here typical prefixes as shorthand for their > namespaces) on an element that is from the glossary namespace - > Soroush and I would think that it actually does not matter if you prefix it > or not. If it is not prefixed it will be "magically" considered of the same > namespace (vocabulary?) as the element, on which it is and not the xlf: > namespace. But also that there is no harm in explicitly prefixing the > attribute. No, prefixed and unprefixed attributes are completely different and you have to decide which way to go. For elements, the following two documents are identical: <foo xmlns=" http://example.com "/> <bar:foo xmlns:bar=" http://example.com "/> When we add attributes, the following two documents are identical, note missing bar: prefix on attribute: <foo a="123" xmlns=" http://example.com "/> <bar:foo a="123" xmlns:bar=" http://example.com "/> And these two documents are completely different from both of: <foo bar:a="123" xmlns=" http://example.com " xmlns:bar=" http://example.com "/> <bar:foo bar:a="123" xmlns:bar=" http://example.com "/> > However, Yves previously said that it is invalid if you prefix an attribute > that is on an element from the SAME namespace. Could you point to the correct thread, so I can comment? I'm just remotely monitoring what's happening in XLIFF world? > What is the best practice? It depends, about which XLIFF feature we are talking about? -- ------------------------------------------------------------------   Jirka Kosek      e-mail: jirka@kosek.cz       http://xmlguru.cz ------------------------------------------------------------------      Professional XML and Web consulting and training services DocBook/DITA customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------  OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. ------------------------------------------------------------------     Bringing you XML Prague conference    http://xmlprague.cz ------------------------------------------------------------------

On 2.12.2014 23:23, Dr. David Filip wrote: > I have to say I am completely confused now. That's very easy with XML namespaces :-) > The above example only uses the gls module namespace apart from the > core namespace that does not have a prefix declared in the example > > Do you say that in the above context > > 1) > <gls:term source="mydictionary">slushy</gls:term> > > is different from > > 2) > <gls:term gls:source="mydictionary">slushy</gls:term> > ? Yes, very different -- source and gls:source are completely different attributes which for example means that in order to read their value in XPath or using some XML API (DOM, SAX, ...) you have to use different code. > My questions are > Is the "source" attribute in 1) in the gls: namespace? No > Is 2) valid? Yes, it's valid against http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/schemas/modules/glossary.xsd > Is the "source" attribute in 2) in the gls: namespace? Yes, but namespace is "urn:oasis:names:tc:xliff:glossary:2.0", prefix is not important at all. And this snippet is not valid against schema I reference above. > Doesn't 2) mean the same as 1) ? No, they are different > 3) > > <gls:term source="mydictionary" itsm:person="John Doe">slushy</gls:term> > > Even if I do not prefix source, which is in the same namespace as > "gls:term", No "source" attribute is not in any namespace. > I assume I have to prefix "person" in 3) to make sure that it > belongs to the itsm: namespace and gets validated against the itsm: schema. > Otherwise it would be assumed to belong to the same vocabulary as gls:term > and fail to validate as there is no attribute "person" in the gls: > namespace, correct? Probably yes, I don't know where schema for itsm is. But schema for glossary requires attributes to be in namespace, except "source". Jirka -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML and Web consulting and training services DocBook/DITA customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. ------------------------------------------------------------------ Bringing you XML Prague conference http://xmlprague.cz ------------------------------------------------------------------ Attachment: signature.asc Description: OpenPGP digital signature

Thanks, Jirko I think I understand now this mind boggling issue :-) except an inconsistency in your answer (?) > Is 2) valid? Yes, it's valid against http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/schemas/modules/glossary.xsd > Is the "source" attribute in 2) in the gls: namespace? Yes, but namespace is "urn:oasis:names:tc:xliff:glossary:2.0", prefix is not important at all. And this snippet is not valid against schema I reference above. You say that 2) is valid against the xsd and a few lines later that "this snippet" (which? 2)?) is not valid against the xsd. I think that 2) is simply not valid in the context of the given test suite example and given the xsd, as the xsd requires the glossary vocabulary attributes not be in a namespace on its elements. I think I understand that the gls: prefixed attribute could be still valid as an extension if the wild card was "any" (or through a wild card on elements from another namespace), but the wildcard in the glossary xsd is "other" (rather than "any"). So I think that it is actually not valid and I think I understand how it is syntactically and semantically different. The key IMHO is the design decision of the xsd authors not to namespace its own attributes on its own elements, which seems the best practice to avoid clutter.. BTW, the itsm xsd has not yet been published, or created, yet the itsm namespace has been declared in the current 2.1 working draft (that has not been published in the standardization sense) although it is publicly available. Cheers and thanks dF  Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer  LRC CNGL 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 3.12.2014 13:17, Dr. David Filip wrote: > Thanks, Jirko > I think I understand now this mind boggling issue :-) > except an inconsistency in your answer (?) > > >> Is 2) valid? >> >> Yes, it's valid against >> >> http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/schemas/modules/glossary.xsd Oops, I though that you were still referring to 1) -- ------------------------------------------------------------------ Jirka Kosek e-mail: jirka@kosek.cz http://xmlguru.cz ------------------------------------------------------------------ Professional XML and Web consulting and training services DocBook/DITA customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------ OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. ------------------------------------------------------------------ Bringing you XML Prague conference http://xmlprague.cz ------------------------------------------------------------------ Attachment: signature.asc Description: OpenPGP digital signature

Perfect, so now everything is clear :-) Dr. David Filip ======================= OASIS XLIFF TC Secretary, Editor, and Liaison Officer  LRC CNGL 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 Wed, Dec 3, 2014 at 12:40 PM, Jirka Kosek < jirka@kosek.cz > wrote: On 3.12.2014 13:17, Dr. David Filip wrote: > Thanks, Jirko > I think I understand now this mind boggling issue :-) > except an inconsistency in your answer (?) > > >> Is 2) valid? >> >> Yes, it's valid against >> >> http://docs.oasis-open.org/xliff/xliff-core/v2.0/os/schemas/modules/glossary.xsd Oops, I though that you were still referring to 1) -- ------------------------------------------------------------------   Jirka Kosek      e-mail: jirka@kosek.cz       http://xmlguru.cz ------------------------------------------------------------------      Professional XML and Web consulting and training services DocBook/DITA customization, custom XSLT/XSL-FO document processing ------------------------------------------------------------------  OASIS DocBook TC member, W3C Invited Expert, ISO JTC1/SC34 rep. ------------------------------------------------------------------     Bringing you XML Prague conference    http://xmlprague.cz ------------------------------------------------------------------