MHonArc v2.4.5 -->
xliff message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [xliff] RE: Filenaming
Title:
John and all:
Thanks for flagging the URL problems and your other general comments and
observations. I've modified the announcement and I think it's all working
correctly now. Please give the URL's a try, and let me know if you continue
to get log-in screens or reference incorrect document versions. I missed
the problems before because if you're already logged into the website in
another open browser window, you don't get queried for log-in.
Regards,
Tony
OASIS members, XML developers, standards and localisation industry
colleagues:
The OASIS XLIFF TC has approved XLIFF 1.1 as a Committee Specification, and
now starts a 45 day public review prior to submitting this specification
to OASIS members for consideration as an OASIS Standard, in accordance with
"Section 2 Standards Process" of the OASIS Technical Committee Process document
(see http://www.oasis-open.org/committees/process.shtml#approval_spec).
The public review starts 11 Aug and ends 24 September 2003.
Link to the XLIFF 1.1 Specification is available at:
http://www.oasis-open.org/committees/xliff/documents/xliff-specification.htm
Link to XLIFF 1.1 Schema is available at:
http://www.oasis-open.org/committees/xliff/documents/xliff-core-1.1.xsd
Link to XLIFF 1.1 Whitepaper is available at:
http://www.oasis-open.org/apps/group_public/download.php/3110/XLIFF-core-whitepaper_1.1-cs.pdf
Comments are welcome from all interested parties and may be submitted to
the XLIFF comment list:
xliff-comment@lists.oasis-open.org
Persons who are not subscribed to this list may post comments to it but will
have to confirm the message via a token return.
Any comments made can be viewed at http://lists.oasis-open.org/archives/xliff-comment/
John Reid wrote:
Since the naming convention is a draft, we may have to rename later no matter what we do. I agree with Tony that we should not rename now but wait for some finality on the naming convention. However, we do need to make sure that we are pointing at the latest documents and that the links work properly.
My original question was whether we should address the June 25 revision of the spec rather than the May 22 revision, which is the one we referenced in the earlier version of the Peer Review Announcement. The May 22 revision points at the June 25 revision as the latest, which could cause some confusion as to what should be reviewed. I like making the reference in the Announcement generic, as proposed by Tony in his latest Peer Review Announcement proposal.
The links in the proposed announcement have two issues, as I see it:
1. The link to the spec finds no document:
http://www.oasis-open.org/committees/xliff/documents/xliff-specification.htm
This is caused by an inadvertent space at the end of the URL. The corrected URL is below.
http://www.oasis-open.org/committees/xliff/documents/xliff-specification.htm
2.- The link to the white paper requires a login:
http://www.oasis-open.org/apps/org/workgroup/xliff/download.php/3110/XLIFF-core-whitepaper_1.1-cs.pdf
Shouldn't this poiint to a public area of OASIS, if this is an at-large peer review?
(Tony and Yves, thanks for all your efforts on this. If there is anything I can do to help out, please let me know.)
regards,
john
Tony Jewtushenko <tony.jewtushenko@oracle.com> 8/6/03 5:36:51 AM >>>
Yves - hold off on any renaming for now.
I see four options for document naming:
1. Leave the names as they are, change them only if peer-review /
standards approval process flunks us on the basis of the document
naming.
* Advantage is that we don't have to make any changes, and
existing applications continue to reference the document.
* Disadvantage is that this may lead to issues being raised
during peer review, possibly leading to rejection of the
spec on the basis of the doc naming convention. And we
will ultimately need to rename, if/when the spec becomes
an approved OASIS standard.
2. Physically rename all the documents now.
* Advantages: naming convention doesn't become an issue
during peer / standards review processes; we define a
process for renaming that can be used in the future.
* Disadvantages: work required renaming and editing
documents; rename will impact existing implementations
that reference the online XSD document
3. Create URL's that logically reference the existing documents -
leave physical document names as they are.
* Advantages: Low impact, superficial modification.
Existing implementations unaffected.
* Disadvantages: Doesn't address the root problem - naming
convention could still become an issue during peer review
that leads to rejection; Will still need to rename
physically if/when XLIFF becomes a standard
4. Create a second version of the documents - maintain originals as well
* Advantages: Moderate level of work. Addresses naming
convention requirements; Existing implementations unaffected.
* Disadvantages: Creates a level of uncertainty which could
lead to confusion - which document names do implementors
reference; Complicates rollout of future revisions;
Potential for documentation getting out of sync;
I'm recommending option #1 as the best course of action - we will
address the naming convention issue at the end of the peer review
period, if and when it becomes an issue. Renaming in haste is a bit
too risky, and could create technical problems during the peer - review
period. It's very likely that we'll have to change the names after the
peer review concludes, before we submit to OASIS for standards review.
Over the next 45 days we must develop a plan for renaming with minimum
disruption and re-work. After we've renamed the spec & supporting
documents (by mid - Sept), we'll have a ballot to accept the renamed
and possibly revised documents as Committee Specification and supporting
documents.
Any comments / disagreements / alternative suggestions?
If there's no further discussion on the issue of renaming, then below
is the proposed text of the XLIFF 1.1. peer review announcement that I
intend to have Karl distribute on Friday. Feel free to comment - but
please be aware that I'm planning to send this to Karl tomorrow
(Thursday):
OASIS members, XML developers, standards and localisation industry
colleagues:
The OASIS XLIFF TC has approved XLIFF 1.1 as a Committee
Specification, and now starts a 45 day public review prior to
submitting this specification to OASIS members for consideration as
an OASIS Standard, in accordance with "Section 2 Standards Process"
of the OASIS Technical Committee Process document (see
http://www.oasis-open.org/committees/process.shtml#approval_spec).
The public review starts 11 Aug and ends 24 September 2003.
Link to the XLIFF 1.1 Specification documents are available at:
http://www.oasis-open.org/committees/xliff/documents/xliff-specification.htm
Link to XLIFF 1.1 Schema is available at:
http://www.oasis-open.org/committees/xliff/documents/xliff-core-1.1.xsd
Link to XLIFF 1.1 Whitepaper is available at:
http://www.oasis-open.org/apps/org/workgroup/xliff/download.php/3110/XLIFF-core-whitepaper_1.1-cs.pdf
Comments are welcome from all interested parties and may be
submitted to the XLIFF comment list:
xliff-comment@lists.oasis-open.org.
Persons who are not subscribed to this list may post comments to it
but will have to confirm the message via a token return.
Any comments made can be viewed at
http://lists.oasis-open.org/archives/xliff-comment/
Gerard Cattin des Bois wrote:
I agree. This naming convention needs revisiting.
Cheers,
-Gérard