OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xliff message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: [xliff] XLIFF Teleconference Minutes - Tuesday,17 Dec 2002


1/Roll Call (5 min)
Tony, Matt, Mark, Mirek, Milan, Christian, Shigemichi, Bryan, David

2/ Previous Meeting Minutes - accept as is or amend.
* Moved to accept: John; 2nd: David; Passed without dissent

3/Review all remaining Open Issues listed in the tracking report. (15
minutes per item max = 90 min) 

- 1. Extending Attribute Values: 
* Action Item: Editor needs to add this to the spec. Owner: Yves

- 2. Context Group PIs: 
* Action Item: Editor needs to remove references to PIs from the spec.
Owner: Yves

- 3. Defaults: 
* Action Item: John's proposal did not make it to the group. He will
resend. we will discuss this in the next meeting. Owner: John

- 4. Phase names in Alt Trans: 
Moved to accept: Mark
2nd: Matt
Passed without dissent
* Action Item: Editor needs to add this to the spec. Owner: Yves

- 5. (Already Closed: Rejected)

- 6. Reformat: 
* Action Item: Matt will get this out this week. We will discuss it in
the next meeting. Owner: Matt

- 7. Context-group "purpose" recommended values.
* Action Item: Editor needs to add this to the spec. Owner: Yves

- 8. (Already Closed: Moot)

- 9. Attribute Enumerated Values: Discussion on listing all enumerated
values for attributes in the specification
> Mark spoke in favor of including enumerated values in
specification.If these values are changed the spec should also be
changed. A dot-release should be made when values change. We do not want
a separate spec for values since we would have synchronization issues. 
> John spoke against. The decision was made early on to separate the
enumerated values from the spec; they were removed to a separate schema
and marked for deletion from the spec. This allows us a great deal of
freedom with these values without affecting the spec. There could be a
separate spec for the values referenced by the 1.1 spec. 
> Doug suggested using a mechanism similar to that employed by HTML in
which the spec is updated as an 'edition'. Example: HTML 1.0 2nd
Edition.
> David spoke in favor. The spec should provide the values. The freedom
expressed by John is provided by issue #1, above ('x-').
> Tony spoke in favor. The spec should contain the values bt te schma
can be separate.
> Christian suggested that the values remain separated but still rev
the spec as values are added. Dealing with updates to the spec and the
values is a separate issue and a new issue should be created for it. The
freedom John spoke of is different than that expressed using the
pattern, 'x-'.

* Action Item: Put together a proposal that may strike a compromise.
Owner: Christian
* Action Item: Add new issue concerning updating the spec/schema/dtd.
Owner: Tony

- 10. Whitespace / List item delimiters:
> Mark pointed out that if schema lists are used for those enumerated
items that can take multiple values, they will not validate properly
with our specified list separator of the semi-colon (;). We should use a
space to separate list items, which is what is specified by the W3C.
> Doug pointed out that nmtokens, idrefs, & entities all needed space
list separators, also. 
> Tony brought up the issue of backward compatibility. If lists were
already implemented based on our current recommendation, they wouldn't
be compatible with this new recommendation. 
> Mark pointed out that the spec only recommends semi-colons for lists
in free text values. The white-space separator is only an issue for
enumerated values.
> John suggested referencing the W3C standard rather than specifying
our own.

* Action Item: Rewrite section D.2. Attribute Names in the spec to
accommodate white space separators in enumerated values. Owner: Mark

- 11. TextContent Extensibility: 
 > Doug proposed that we add 'any' to the TextContent so that we have
an extension point within the text of and . This would allow xhtml. If
an editor understands xhtml, this would be advantageous.
 > Shigemichi pointed out that this would be problematic for editors
and TMs because they would have to understand these tags and know how to
process them. These tags would have to be processed to the by these
systems.
 > Doug suggested treating any unknown code as a tag. He pointed out
that xliff editors and TM systems would need to be forward compatible;
thus, should have a default behavior of treating unknown (future) codes
as .
 > Tony suggested adding those xhtml tags Doug needs. However, Doug
indicated he would want a lot supported. There was some discussion about
adding xhtml support to XLIFF. 
 > Christian and John pointed out that there are a number of other
formats that someone may want to supported, also. This only simplifies
the problem for the xhtml producer but pushes the problem of supporting
more than xliff format within text to the xliff tool vendors. 

* Action Item: none. This was tabled until the next meeting due to
time.

4/Schedule of remaining work (10 minutes)
- Reformat proposal, Matt
- Defaults proposal, John
- Enumerated values in Spec proposal, Christian
- Lists Separator, Mark
- Update issue
- Extensions in TextContent
- phase-name in proposal, John
Allow three meetings to these discussions; 
Release Candidate on Jan. 29. 
Allow two meetings discussion of spec changes.
Feb 11 target date

5/ Feedback and discussion on Mark's forwarded Free Standards Group
Open Internationalisation Initiative's Common XML Locale Announcement -
should the XLIFF TC arrange an official liaison relationship with this
group?
 > Mark brought this to the groups attention. He is not involved nor
has plans to join. None showed interest in working with that group.

6/Any New Business
 > none

7/Next meeting - Tues, 7 Jan 2003, 04:00PM Europe/London/Dublin / 08:00
AM PST




---------------------------------------------------
John Reid
Snr SW Eng, Internationalization
jreid@novell.com
(801) 861-3855 

Mailstop Prv-H433

Novell, Inc., the leading provider of Net business solutions
www.novell.com
----------------------------------------------------



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC