ITS WG - Prague 2007 f2f

 

 

agenda review

Yves: same as original agenda, plus dicsussino on ITS2XLIFF and other outreach activities on last meeting day

Gathering issues in the document

status section

Jirka: "A complete list of changes to this document is available. " appear two times in status sectino

introduction

Felix, Yves: propose to reqrite introdcution

Richard: need to be consistent with first mention of references, subsequent mention of reference

"1.1 Who should use this document"

Yves: intended to the designers will ibe "ntended for the designers "

Felix: propose to go through document to be consistent wth "desginers" and "developers"

1.2. How to use this document

"choices they should do in order" > "choices they should make in order"

"Many of these best practices do not require the XML format used to have been developed especially for internationalization."

Richard: above sentence is difficult to understand
... in general, use more active voice, addressing reader with "you" etc.
... less passive
... subsections "content authors" and "developers", or bold (if not subsections) in sec. 1.2

"This illustrates many of the guidelines in this document.". Put "section" after "This"

Felix: need to say something about sec. for here (in sec. 1.2)

"Think twice before creating your own schema. Consider strongly existing formats such as DITA, DocBook, Open Document Format, Office Open XML, XML User Interface Language, Universal Business Language, etc. Those formats have many insights built-in."

Need references for the formats mentioned above

Jirka: need to be consistent with abbreviations like "XSD" vs. "XML Schema", and have a glossary at the end of document.,

"NVDL, which can amongst others"

Richard, Jirka: this paragraph needs to be made clearer

"difference in conformance profiles" > "differences in conformance profiles"

"requirements to XML Schema part 1" needs closing bracket

"If you are working with XSD, your options depend on the question whether the schemas involved define target namespaces (techniques such as working "chameleon" or "proxy" schemas may be considered as solutions in certain cases)."

Need to go back to Christian with above paragraph and figure out what he wanted to say

In general on material about on creating / modifying schemas:: language / formulations need to be reworked

"2 When Designing an XML Application"

"should take to account" > "should take into account"

bullet list before table can be removed, since we have the table

on the first table

list of BP should be just BP, without saying "Best Practice 1: ..." (needs modification of specref processing

"Note that the column “For Existing Schemas and DTDs” assumes that your excising schema already provides internationalization related functionality. That is: there is no need to use [ITS 1.0] markup directly, but the existing markup only needs to be associated with [ITS 1.0] following sec .5.5 “Associating ITS Data Categories with Existing Markup”, or the mechanisms for pointing to...

scribe: existing information described in sec. 5.2.1 of [ITS 1.0] need to be applied. "

Proposal from Felix to move before the table

Richard: three cases: no schema at all, needs to be created. second: existing schema needs additional i18n markup. Third case: you have a schema with i18n functionality, which needs to be associated with ITS

naming of columns need to be reworked.

Richard: "adding new functionlaity " vs. "adapting existing functionality".

Jrika: "DTD or schema" is used very often. Just "schema" should be fine

Yes: propose to skip table for now, come back to it after rewriting the sections

now "Best Practice 1: Provide xml:lang to specify natural language content"

"Include Include xml:lang in your DTD or schema to allow specifying the natural language for the root element and any element where a change of natural language may occur."

rewrite above adds "for the root element and"

"to allow specifying" > "to allow specification of"

" ITS does not provide remedy for this." > "ITS does not provide a remedy for this."

"!Note: If not the language of the content, but a natural language value as data or meta-data about something external to the document has to be specified, an attribute different from xml:lang (like hreflang in XHTML) should be used."

above paragraph is German English, needs to be internationalizded

Richard,, Yves: first paragraph after blue text is often similar to the blue text.

that's a general issue for many BPs, needs to be harmonized / reworked

Richard: notes in this sec. are mostly paragraphs

need to decide what stays as a note, what becomse a paragraph

probably all except hte 3rd one will be paragraphs

shte/the/

Felix: sometimes we say "x element", sometimes "element x", sometimes code markup, somtetimes not. This needs to be harmozied

issue: HREFLANG is not used often

we need a better example here

rewrite proposal for the "Make sure" note (last note)

"The XML Schema built-in data type language does not allow empty values. However, the declaration for xml:lang in the XML Schema document for the XML namespace at http://www.w3.org/2001/xml.xsd does allow for empty values and therefore can be used."

<r007a> http://www.w3.org/International/questions/qa-when-xmllang

(URI has examples for HREFLANG issue)

Richard: need real "HOW TO DO THIS" mateiral for various schema languages

see e.g. 4.2.1 4.2.2, and 4.2.3

Richard: General comemnt: "For existing DTD and schema:" should be subsection

in addition to a subsection for new schemas

Richard: current blue part is only relevant for new schemas
... summary here is biased to new schemas, needs to be changed

now example 2 "Non-standard way of declaring language information"

discussion whether this should be reworked.

"Problematic example, since the inheritance behavior of xml:lang is not given. Proposal: add a remark about this fact."

Richard: +1

example 2 is problematic, see "Best Practice 12: Use multilingual documents with caution.". Needs to be made clear

Example 3

"Use the following rule to specify that the langcode element holds the same values as the xml:lang attribute."

add "and applies to the text element"

Richard: example 2 and 3 are one examples, could be merged

general issue for many examples, sometimes merged issues might be very long

example line wrapping issue - could be solved by CSS

Richard: we have how to do information in the "why to do" section
... and "why to do section" relates only to the new schemas

"Best Practice 2: Provide a way to specify text directionality"

Richard: problem in blue paragraph as well, needs discussion

"the user to specify the base writing direction of blocks, embeddings and overrides for the Unicode bidirectional algorithm."

Felix: might need a check from Richard

Yves: "Why do this" : need we a list of BIDI languages?

Now "Best Practice 3: Avoid translatable attributes"

Yves: rewrite first sentence of first bullet point of "Why dot this" section

Felix: on example 7: "For example, if it can be avoided, do not allow this" rather than "do not allow this:", since the example is so common

Richard: : again problem: no good differentation between new and existing shcemas case, that will apply to nearly all BPs

s//

Richard: "why do this" there is the need to mention inline labeling of language in the "why do this" section
... don't understand the note before "resources" section
... that note should be in "how to do this" section
... note should say "this is not a solution, just the best you can do "

Yves: that is always the case

(discussion to be continued)

Felix: "Normally, those markers are elements, but elements cannot be used within an attribute value."
... porpose to say "Normally, those markers are segmented via element boundaries, but elements cannot be used within an attribute value."

Now "Best Practice 4: Indicate the translatability of elements and attributes"

Jirka: issue in example 9: element with alt attribute should not be in del element

Felix: in "why do this" section: "this default assumptions" should be "this default assumption"

Richard: general question: what links should be in the resources section, how do you choose that?

Now "Best Practice 5: Provide a way to override translatability information"

Yves: on "The its:translate attribute and the its:translateRule element are part of the ITS "Translate" data category which expresses information about whether the content of an element or attribute should be translated or not."
... this paragraph is repeated in soem BP, in others not , needs to be consistent
... need a link to ITS translate data category in 5th paragraph
... also in 1st paragrpah of example 11

Felix: before example 11 it says "Both have the same semantics as its:translate,"
... propose to say "Both have the same semantics as its:translate, that is: the translation information applies to element content, including child elements, but excluding attribute values."

Yves: example 11 needs a 4fh rule
... which would be identical to 2nd rule, but covering translate="yes"

Richard: difference between BP 4 and BP 5 needs to be clearer

Now "Best Practice 6: Provide text segmentation-related information"

Felix: “mixed content” refers to element declarations. This BP can be used without a schema at all and encompasses elements which contain only text or only elements, hence let’s just delete “mixed content”.

Yves: "The element fn should be treated as a nested an independent run of text.":
... delete "an"
... in "why do this": "without knowing about the semantic of the elements."
... drop "about", change semantic > semantics

Now "Best Practice 7: Provide a way to specify ruby text"

Richard: blue text is too specific

Yves: on paragraph before "Example 14": sometimes we say "associated to", sometimes "associated with". Not sure what is right

Richard: here it's "with"
... in BP 7: need to say s.t. about conformance levels of W3C ITS spec
... second paragraph of "How to do this section" is not "how to do this"
... need to say in "For Existing DTD or schema" that this works only if you have the same semantics
... "Include its:ruby in you DTD " you should be "your"

Now "Best Practice 8: Provide a way to specify comments for localizers"

Richard: title should be the blue text

Felix: need to be clearer: relation between "comments", "notes", instructions, ...

Jirka: "Note: The its:rules element can be created in a separate file, but it is more efficient to allow the authors to include the rules directly into their documents." needs to be justifyfied

Yves: "tell the translator how to translate part of the content" not really necessary

Felix: bullet points which continue a sentence are sometimes capitalized, sometimes not

"Explain why text is not translated" > "Explain why text is not to be translated"

Felix: general: spelling of "re use": dash or not?

Yves: "Make sure to have an ID attribute available for the elements that contain translatable text."
... propose to say : "Make sure that the elements with translatable content are associated with
... a unique identifier"

Richard: similar reworindgs needed for paragraph 2 and 3

Yves: "It is strongly recommended for such ID attribute to be of type ID"
... should be "It is strongly recommended for such identifier to be an attribute of of type ID"

Richard: "build-in" > "built-in"

Now "Best Practice 10: Identify terminology-related elements"

Felix: issue: This BP sometimes talkes about “elements”, sometimes about “markup”. This should be harmonized.
... example 19: last rule should be <its:termRule selector="//dt[../dd]" term="yes" termInfoPointer="../dd"/>

Richard: first sentence of "Why do this" section needs rewrite

Yves: replace "target" > "translated"

Felix: concerns about "iIdentified terms could be used for indexing" paragraph
... Identifying terms is important for indexing in every language. But that’s independent of language specific needs for index creation, like transliteration of Kanji to Hiragana for an index. Also, I think nobody would add transliteration information into the source document, but use a dictionary during the index creation step. Hence, I think we don’t need this paragraph.

Felix another concern on this BP in general:

Is this BP / the “Terminology“data category for providing information to human readers or non-human processing? If it is both, we need to make clear that an implementation has to provide additional means for differentiation, like a termInfoType attribute with values “humanreadable” vs. “databaselink” vs …, or just human-readable documentation (“in our documents, terminology...

scribe: information is always for data base linking …”.

Yves: No need for "As a result" in last paragraph of "Why do this" section

Now "Best Practice 11: Provide a way to override terminology-related information"

some spelling errors, fixed

Yves: general comment: we don't mention is:span anywhere, we might need a new BP for that

Now "Best Practice 12: Use multilingual documents with caution"

some typos, fixed

Richard: last two paragraphs of "why do this" should be bulleted list
... need more clarity: why do you need to start with single language documents

Yves: I think that is said in the "why do this section"

Richard: the note after example 22 raises the question
... general issue: strategy for titles of best practices

Jirka: on Example 20: Bad design
... why <text xml:lang="ja"></text> has no content?

Yves: that was intentional, sometimes we get such data

Jirka: maybe make that explicit?

Now "Best Practice 13: Name elements and attributes with caution"

"Use a fix" > Use a fixed"

Richard: better "don't create names dynamically"

Felix: comment on example 26
... This is bad since the xml:id attributes are overloaded: they both identify and classify <str> elements. Proposal: use a type attribute instead of xml:id

Now "Best Practice 14: Provide an ITS rules for your DTD or schema"

Jirka: general comment: we often say "XSL", but mean "XSLT"
... needs to be fixed

Felix: Do we want to encourage people to declare its:rules specific to their needs? If no, this should be “the its:rules” element. If yes, it should be “an its:rules” element, and we need to make clear that people possibly have to adapt its:rules.

discussion that this issue is independent of this BP,

Richard: its:span element is missing

Yves: not missing on BP 14. We rather need a different BP about its:span

Richard: clarify that BP 14 relates to what you have implemented (no matter if done through ITS or not)

Felix: " For example, DocBook has been used to document XSL. " Propose to delete this sentence

Yves: " ITS rules files are a good choice for the following reasons:" needs rewording

Felix: on example 27: Example is incomplete, e.g. the TEI header encompasses elements with natural language, hence <its:translateRule selector="//header" ranslate="no"/>

is too general. Proposal: use a different example, or ask Sebastian and / or to write a real its:rules file for sec. 5.2. I have high preference for the latter

Now sec. 3.

Again not going through the table, starting with "Best Practice 15: Specify the language of the content!!

Yves: s.t. missing on paragraph 1 of "how to do this"

Felix: example 29 : Example needs a reference to Best Practice 12: Use multilingual documents with caution
... example 29 again: The values for German and Japanese sound strange. Need to check these and others.

Richard: BP should mention that you have to use span element sometimes

Felix: example: 30:: lanngrule should be

<its:langRule selector="//lang[@code]" langPointer="@code" />

Felix: General fix for pointer attributes: XPath in selector attribute needs to check for match of relative XPath expression in pointer attribut

Yves: terminology: mentioning of "ITS rule", "ITS rule file" e.t.c should be conistend

s/conistendconsistent/

Richard: in section for authors: are we loosing distinction between "how to do this" and "why to do this"?

Yves: we don't have that distinction here

Richard: should text before example29 be a note?

Felix "selecting proper formatting properties for data such as date, time, numbers, etc."

scribe: propose to drop the bullet point

Richard: reference links
... put "Language tags in HTML and XML" first, BCP 47 after

Now "Best Practice 16: Specify text directionality if needed"

Felix: "It is not recommended to use Unicode Bidi Embedding Controls in an XML document." > add "see Unicode in XML"

Richard: suggest to link to one of the articles

<r12a-CZ> http://www.w3.org/International/questions/qa-bidi-controls

<r12a-CZ> Bidi formatting codes vs. markup in (X)HTML

Felix: fine by me

Best Practice 17: Override translatability information if needed

Richard: still on BP 16: address "why not use CSS"?
... and : "why not using xml:lang to achieve the same result"

Now BP 17

some typos

"One thing that may be helpful in helping" in example 35 sounds strange

Now "Best Practice 18: Assign unique identifiers to text items when possible"

Richard: still on BP 17:
... note should go higher
... general: who writes the ITS rules?

Yves: your DTD or schema should come with ITS rules. After ,you can change them if you want to

Felix: idea to have a general statement (e..g in intdocution) which says: this is the knowledge you need to understand these subparts of the document

Richard: when transitioning between "simple use of ITS" and "use of ITS rules", you need a sentence saying "you may have the knowledge (or not) to do this"

Now REALLY "Best Practice 18: Assign unique identifiers to text items when possible"

Jirka: "Make sure to assign a unique identifier to any element where it can be set.": not sure if this makes sense
... e.g. might be too fine grained for inline-elements

Felix: " If possible, use globally unique and persistent values as identifiers"
... I’m confused: should just the values of the attribute be unique, or is it OK to use a different mechanism than ID type attributes? The note in BP 9 “Using identifiers that are globally unique (i.e. unique across any documents) and persistent (i.e. ones which do not change over time) often provides additional benefits.” Suggested the latter

typo fixed

Now "Best Practice 19: Avoid CDATA sections when possible"

Felix: CDATA should always be "CDATA sections", not just CDATA or "CDATA notation

Yves: "Instead, author for this:" needs to be reworded

Felix: on "for example if the CDATA section encloses a script or an XML example"
... What are the cases you are not able to do this? These should be mentioned, otherwise drop “for example if the CDATA section encloses a script or an XML example”.
... on the last two notes before the "why to do this" section:
... Propose "Note: CDATA sections are often used to store content with HTML or XML markup, which is not recommended. See Best Practice 25: Avoid storing markup as text for more details"
... and "Note: Using CDATA sections " for second note

Richard: need an example of xinclude or xlink
... also, 2nd paragraph of "why do this"
... the problem is valid also for translating documents, not just changing the encoding

Now "Best Practice 20: Provide comments for localizers"

Felix: Same issue as with BP 8: do we talk about comments or notes? I’d prefer the latter. Note: my comment is about the whole BPs 8 and 20, not only the titles.

Richard: general issue: why having examples in separate files?

Yves: makes it possible to validate examples, and in that way, we don't need to use CDATA sections

Jirka: identation in example38 looks wrong

Now "Best Practice 21: Ensure any inserted text is context-independent"

Jirka: value of conref on example41 looks strange

Felix: We should ask the DITA folks specifically for feedback on this, since they have worked on a lot of related material.

Yves: on "The article/noun separation also causes trouble for the translator: Without any easy way to see the actual term when translating the paragraph, she may not be able to decide the gender of the article."
... "she" should be "they"

Felix: if DITA material is published, have a link to that?

Now "Best Practice 22: Use entity references with caution"

Richard: example 39 and 40 are not illustrating the point correctly

Yves: on BP 22: prropose to drop this

Jirka, Felix +1

Now "Best Practice 23: Place sub-flow elements with caution"

"Place sub-flow elements where they have the least negative impact on the parent text flow."

Felix: Not sure what negative impact is

Yves: maybe we don't need this BP.

Jirka, Felix: drop it

NOw "Best Practice 24: Identify terms"

some typos

Yves: "This is more efficient than adding markup in the body of the document." in example 44: , add "for each instance of the UI element"
... " the translation project manager": no need to mention these

Richard "why do this" section needs to be rearranged

scribe: main reason for the section is that terms should be marked up
... not the overriding case

Now "Best Practice 25: Avoid storing markup as text"

Jirka: "use the XML namespace mechanism to" should be "use the XML namespaces mechanism to"
... "If you must use include markup as text content:"
... delete "use"

Yves: "Make sure to document the type of content it contains": "it" needs a subject

Richard: : BP 25 not clear what the problem is

Yves: now way of knowing that something is source oode of tags
... hard for machine processing like "give me all HTML tags"

Richard: "Avoid storing XML or HTML markup as text content." could be "use namespaces for incorporating markup"

Now "4 Generic Techniques"

Now 4.1

"Writing ITS Rules"

Yves: two notes should not be notes, but paragraphs

Richard: why techniques in sec. 4 are not BP?

Felix: these are a kind of meta info you might need for applying sec. 2 / sec 3 BPs

Richard: ok

Felix: "Some rules may be more complex to take into account all the aspects of inheritance."
... don't understand the sentence

Yves: for example 48
... need to be consistent with "non-translatable", "not translatable" etc.

Now sec. 4.1.1

Now "4.1.2 Dealing with namespaces"

needs more examples

Now "4.1.3 Create your XPath expressions with care

"following general dimensions should be considered:"

drop "general dimensions" and say "the following"

"The values of ITS pointer attributes are XPath relative location paths"

Felix: propse to have a list of these attributes with links to their declaration

Yves: "In environments where XSLT is used to process ITS-related XPath expression" should be bullet point as well

"In addition to these dimensions, " > In addition to these aspects"

Now 4.2

Felix: These examples cannot be generalized. There are tons of other, schema language specific mechanisms for adding attributes. Propposal: change the title to “Example of adding an Attribute to an Existing DTD or Schema”, and add “Note that these examples only show a few ways of adding attributes. There are many others, depending. on the chema language and e.g. the modularization...
... techniques used in the existing schema.” Other proposal: delete this section …
... in 4.2.1, propose a lnk to http://www.w3.org/2001/xml.xsd .

Jirka: propsoe to unify examples. E.g., each example currenlty defines a differenlty named element
... example 52 needs to be changed to have the union type
... I'll provide a declaration

Richard: general issue: there need to be more references from sec. 2 and sec. 3 to sec. 4

Felix: on XHTML modlurazatoin sectoin: not sur eif we should remove it

Richard: let's keep it in here for now and tell XHTML2 people
... that it is "at risk"

Felix: +1