See also: IRC log
yesterday minutes: http://www.w3.org/2006/04/19-i18nits-minutes.html and http://www.w3.org/2006/04/19-i18nits-regular-call-minutes.html
open issues are at http://www.w3.org/Bugs/Public/buglist.cgi?query_format=specific&order=relevance+desc&product=ITS
yves: need to discuss terminology
... and element within text
... terminology and terminology data
category need to be discussed (possibly together), so 2869 together with 2877
... continue discussion with
http://www.w3.org/Bugs/Public/show_bug.cgi?id=2969
<xsl:value-of select="@a"/>
<xsl:copy-of select="@a"/>
<xsl:copy-of select="string(@a)"/>
Felix: the third example would be an error
... because the copy-of expects as the value of "select" a node,
not a string
<scribe> ACTION: Yves to explore the reference attributes (termRef, locRef) with regard to spliting URI "base versus fragment" [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action01]
sebastian: we would need a real life example for this
yves: we said we will have a matrix, sliced by each data category and selection mechanisms
... that would
help to advance the working draft in the W3C process
... that is the main focus. in addition to that we would have tests for error examples
... i.e. to help developers to test their code. We say: these error examples are not the main purpose, clearly separated
felix: we need s.t. like http://www.w3.org/2006/04/charmod-resid-implementation/ for us
yves: in the colum "implementation", we point to implementations, including input, output for a specific test
sebastian: what is the output? e.g. "should this be green or red"?
felix: http://www.w3.org/International/its/tests/xmlspec1-output.xml would be a format example
sebastian: how about inheritance? Do you have to say s.t. in the result about it?
yves: you decorate the tree with s.t. like:
... <bla at1 at2 .../> would be decorated as
<bla bla-trans=".." at1-trans=".." at2-trans=".."/>
yves: do we need to force to decorate for everything?
... or a single output
... we can have several
types of output, see e.g. the examples at http://www.w3.org/International/its/tests/#Generic_001
sebastian: that would need human checking wether 2 implementations are doing the right thing
... a list of
all text and attribute nodes
... we don't want to see element nodes, but text nodes
... for e.g. ITS span, that would generate a text
node
felix: so /spec[1]/body[1] should be /spec[1]/body[1]/text()
sebastian: the equivalent of "red" and "green" in HTML, but you show the text
... you then can automate
that
... you wrap it up in XML elements, possibly normalized
... normalization changes things, but it does not matter, since this only for
testing & comparing
... time schedule for this?
yves: before the next face-2-face, or after
... so for "translatability", we have an text node as an
output
... for termRef, we have the URI selected
<scribe> ACTION: all to try out the "translate" test case to achieve compatibility of output [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action02]
sebastian: we can run schematron tests to run invalid combinations, one for local attributes, one for rules elements
<scribe> ACTION: Sebastian to validate the examples in the spec [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action03]
felix: have a small set of tests for now, since features might get dropped again during last call
sebastian: tests might help us to demonstrate why the features are necessary
felix: o.k., just don't create all combinations now (e.g. for "ns or not ns element")
<scribe> ACTION: all to work on examples: christian takes 1-9, felix 10-18, sebastian 19-28, Yves 29 - 37 [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action04]
latest draft: http://www.w3.org/International/its/requirements/Overview.html
yves: have a separate section for the requirements we decided not to tackle for this version of ITS
... some
of the requirements are tackled through the techniques document
felix: some things are not in the requirements document, but in the tagset draft, e.g. elements within text
yves: "Requirements for this document are formulated in [ITS REQ]." in the tagset draft: we should not list
specific requirements here
... "This document covers some of the requirements formulated in [ITS REQ]. Other requirements are covered in [XML
i18n Tech, formal name to be confirmed]
... is that o.k.?
sebastian: +1
<scribe> ACTION: christian to change the statement about the requirements in the introduction (text above the action item) [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action05]
<scribe> ACTION: Yves to rework the requirements document [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action06]
yves: I might have to add some things, I will post changes
... we could publish the 3 documents
together
... the techniques document is less important than the requirements doc
felix: I take out sec. 7 of the tagset doc, convert it to xmlspec, clean up links to and from the section , so that Yves can use the section for the techniques document
<scribe> ACTION: felix to cut sec. 7 out of the tagset draft, to make it ready for the techniques document [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action07]
yves describes the current content of the techniques document, see http://www.w3.org/International/its/techniques/its-techniques.html
sebastian: does this document have a section saying "when should you use ITS?"
yves: it is hard to say this in general, it is specific to subtopics / sections
... e.g. what will be at
http://www.w3.org/International/its/techniques/its-techniques.html#DevLocInfo
sebastian: what is the relationship between the tagset doc ond the techniques doc?
yves: techniques document is pointing to ITS, and the other way round, and there should be a general section in the techniques doc pointing to the tagset doc
christian: how about having a different structure
yves: the current structure is for the main readers
felix: how about an index?
yves: that can not work like multiple structures
christian: how about having pointers to the tagset doc?
yves: that does not work as well
... what you propose look likes the next stage, e.g. the schema developer
needs s.t. different than the content author
... we need s.t. different for the tagset explanatation
christian: I want to have a statement like "if you want to design a new xml application, use ITS"
yves: in sec 2., we could have a subsection "ITS tagset related tasks"
christian: I want a paragraph before 2.1, which focuses on the tagset document
yves: I don't think people have to look at the tagset document, if they do everything right, the techniques
document is enough
... but we could point to the tagset doc indirectly, in various subsections
... where would we put the modularization
stuff?
... how about a section called "examples of ITS usage?" which uses that?
... and having a pointer to ITS, where it makes sense
sebastian: how do we update the techniques document?
felix: we can have "asking for feedback" also in W3C Notes, see e.g. http://www.w3.org/TR/timezone/
yves: summary: we need to integrate modularizations
... the question is: how to generalize the examples for
TEI and xmlspec?
sebastian: it is a very special task, hard to generalize
... we would need an example of how to integrate
ITS into a schema
... a general one, and then the specific ones from the tagset doc
yves: a table with a list of elements / attributes would be great
sebastian: easy to produce from the ODD document
... example is at
http://www.tei-c.org/release/doc/tei-p5-doc/html/ref-encodingDesc.html
yves: we should have one imaginery example for each schema language
... in the XML vocabulary specific
sections, we show the specific examples
sebastian: the specific section about host languages, we could mention how the examples relate to general
cases
... as you integrate stuff in a schema, first check what is needed, e.g. if you need local ITS attributes everywhere
... after that,
see what is easy to do with the schema you have, e.g. "is there a global attributes group which is easy to change?"
yves: so we should not have stuff like http://www.w3.org/International/its/techniques/its-techniques.html#DevLang , but say "integrate xml:lang" and have a general example
christian: how about the difference between textual content and e.g. <img>?
felix: would not work with what we have at http://www.w3.org/TR/its/#selection-defaults-etc , because we select only textual content
christian: how about having a flag "process='no'" for translatability and localization information?
yves: only global
... but maybe also local, e.g. for elements with pointers to files like
<src>myfile.png</png>
<scribe> ACTION: christian to write s.t. about the "process=no" flag proposal for the tagset draft [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action08]
yves: this is just another piece of ITS information, like translate="yes", which is attached to the node
...
but maybe there is a cleaner way to do it
sebastian: is the instance more important?
yves: the relationship is global, you might see it several times
... it has to be done by rule
felix: how about locInfoRef or locInfoRefPointer? are they handled the same
yves: yes, it is just one more piece of information
felix: so it should be not a new data category for this kind of processing, but an extension of existing
categories
... another possiblity: people could do this "on the other side of the API", that is: use schema information after ITS processing,
which does the notation handling
Sebastian: how about making explicit at http://www.w3.org/International/its/itstagset/itstagset.html#selection-global , that you MUST NOT point to s.t. else than element and attribute nodes?
yves: I see the need for pointing to comments in the ref (NOT pointer) attributes
felix: I made the change to http://www.w3.org/International/its/itstagset/itstagset.html#selection-global
tea break
christian left the building, Richard comes in
yves: we would like to do the last call soon, so we question is what to do with the additional ruby conformance
level Richard proposed
... if we still need a pointer to the attribute rbspan
<scribe> ACTION: felix to add a rbspanPointer attribute to rubyRule [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action09]
Richard: some people support simple ruby, complex ruby is not widely supported, because it is complex
<scribe> ACTION: felix to change the RFC 2119 keywords to upper case [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action10]
Richard: the i18n core working group should discuss a third conformance level for ruby
<scribe> ACTION: Richard to discuss the third conformance level of ruby to the core working group [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action11]
yves: we refer to a specific version of the ruby spec. If there is a new version of that spec, we make an errata
richard: so there won't be a third level for ruby before the last call of the tagset draft
richard: would you point to the techniques doc from the tagset spec?
yves: we want to republish the requirement doc, the first draft of the techniques and the tagset last call
together
... so we could point to the techniques document from the tagset draft
richard: we should call the "techniques doc" a "best practices" document
... I would have separate
documents
felix: could it when achieve the purpose "explain general i18n techniques, explain ITS tagset, and how they
relate to each other"?
... what would happen if they are separated? Is it still easy to point to them
yves: we could start with one document and then see later if we need more
richard: in GEO we were really relieved that we split documents
... because tests can be updated easier, and
sections added
... it is easier to publish
felix: are these things also relevant for the techniques here? Maybe not
yves: we don't need to decide right now, it is easy to split later
yves: we looked at other techniques docs like MWBP 1.0
... we decided to do not that design, but like the
other techniques docs in the i18n activity
... but there are some issues:
... it is difficult to give detailed examples for each task in
ITS
... so we would have a general example for e.g. adding an attribute
... the other techniques docs in i18n seem to be specific to tasks,
so maybe that does not fit
richard: the current design of
http://www.w3.org/International/techniques/language#langvalues uses an approach of general statements, and then some specific examples
...
this is a new approach in geo. But we try to have a very general statement , and then specific examples
felix: e.g. if the question is "how to add ruby to a schema?", there are many answers, depending on the schema language / the schema design
richard: we would have the general statement "add ruby to the schema" and point to the examples we have
yves: the same would need to be done for the techniques about including xml:lang in a schema, see http://www.w3.org/International/its/techniques/its-techniques.html#DevLang ?
richard: yes
yves: as for levels of topics in the techniques doc: we want to have several levels, e.g. a specific one about
ITS tagset related stuff
... is that a problem for the techniques structure?
richard: should be o.k.
<scribe> ACTION: richard to give yves the latest stylesheets and css etc. for the techniques document [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action12]
<scribe> ACTION: richard to discuss with people whether we should change the title of the "techniques doc" to "best practices", before last call of tagset draft [recorded in http://www.w3.org/2006/04/20-i18nits-minutes.html#action13]
yves: we have several users, e.g. content authors and schema designers
richard: why don't you have seperate documents for each user
yves: I would make an index at the beginning of the document for the different user groups, e.g. saying "as a content author, read this ..."
richard: how much overlap do we have?
yves: the general part about ITS is useful for many groups
richard: so a separate document would be useful
felix: there is an overlap between users, and many user groups, so separate documents would be hard to achieve
richard: a separation via tasks would be another criterion
... e.g. "how to put ITS stuff in the DTD" or
"how to use global rules"
yves: how would you organize that at a high level?
richard: you would organize tasks within a lower level
yves: the first working draft will look like what we have now
... that is only a first pass
richard: the table of contents should give you an overview, but not necessarily navigate you through the
document
... that can be done by a different document, or the techniques index
... at the i18n site, it is a network of topics, rather than
a hard-wired hierarchy
yves: earliest date will be 2nd week of september
... that would be 12, 13, 14 of September
... we said
it would be Boulder
richard: three questions: translation versus localization?
... is the image in the text or not?
...
(scribe did not hear last question)
... xml:lang might be a solution, see http://www.w3.org/International/questions/qa-when-xmllang
scribe: or the object the uri points to
felix: that is what christian proposes
... <translateRule select="//img/@src" its:translate="yes"
process="no"/>
yves: it should not be "process", but follow="yes"
... to say "I need to follow that value for an additional
process"
... this is for external objects only, e.g. images, sounds e.g.
richard: or e.g. "handle-as-object" = "yes"
yves: how about DITA? They have a conref attribute which points to a whole document
richard: translate should be taken literally
... translate means "deal with text"
yves: do we need this level of "selection"?
felix: how about //src reffering-to-object="yes" with <src>xyz<b/>xyz</src> versus <src>example.com#img1</src>
yves: it does not matter, we provide the value
... if it breaks, it breaks
... what I am afraid about:
it is not really useful
... it is only from the "completeness" standpoint of view nice
richard: a practical application: you might want to say "all icons are translatable, but not these two ones"
yves: it is doable, but maybe not practical. It is not something we should not have, but we are introducting
something which we have not thought through totally
... e.g. there are various types of inclusion like DITA conref. How to deal with all of
them, not only images?
... do we need it for translate, locInfo, directionality?
felix: @dir just manipulates textual content
yves: how about the alignment in tables, it is also influenced by @dir
... anyway, the thing is we would
need additional data categories
... if you want to apply it to several data categories, you cannot make it as an extension to data
categories
richard: I'm not sure if it is a property of non-parsable entities
yves: the topic is borderline on the content of xml, and the charter, because this is not xml