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] | [List Home]


Subject: RE: [xliff] FW: Degrees of constraint (RE: [xliff] Groups -XLIFF TC Monthly Teleconference modified


Hi All,
1) We need a mechanism to handle the various problems we've recently encountered without modifying the spec each time.
2) We need to maintain a useful amount of interoperability.
3) IMO, our previous attempts at enumerating possibilities for interoperability's sake were inadequate (HTML not well represented in restype) so there is no reason to think we won't need to revisit this again and again.
4) All too often I've seen misuse of a feature which causes headaches for downstream processes. I forsee an XLIFF file that contains an element from another namespace with an unfound schema which contains the text to localize; e.g. ...

 <source><foo:bar>unknown content intended to be localized</foo:bar><source>

Option 5 would consider this valid, which it would be, but does it maintain a useful ammount of interoperability?

If there is a way to prohibit the above yet allow unconstrained namespace, I'm all for it. Otherwise, I think we need to maintain some control. Possibly, we could constrain the namespace but create a mechanism to register a namespace through a gatekeeper mechanism. (However, that introduces another set of issues.)

Cheers,
john


>>> "Gerard Cattin des Bois" <gcatt@windows.microsoft.com> 7/19/04 3:19:58 PM >>>
Hello Bryan. Me too. I like option 5.

Cheers,
-Gérard 

-----Original Message-----
From: bryan.s.schnabel@exgate.tek.com [mailto:bryan.s.schnabel@exgate.tek.com] 
Sent: Monday, July 19, 2004 1:37 PM
To: xliff@lists.oasis-open.org 
Subject: [xliff] FW: Degrees of constraint (RE: [xliff] Groups - XLIFF TC Monthly Teleconference modified)


Hello all,

Tony asked me to forward this to the TC.  It concerns the different options
for providing extension points in Source and Target.  I know it's kind of
twisty to read. . .  

I guess I like (5) myself.  I'm experimenting to see how the different XSD
processors deal with the strict attribute.

Thanks,

Bryan


-----Original Message-----
From: Schnabel, Bryan S 
Sent: Monday, July 19, 2004 11:34 AM
To: 'tony.jewtushenko@oracle.com'
Subject: RE: [xliff] Groups - XLIFF TC Monthly Teleconference modified


Hi Tony,

I made a comment on the ballot regarding the degrees to which extension
points for Source and Target could be constrained.  I suggested it might be
useful to construct a matrix to list the degrees from most constrained to
least constrained.  I jotted down some notes along that thought.  

I leave it to you to decide if it's relevant, or not.  I can see how it
might be diving into the details a bit too soon for purposes of this ballot.

Anyhow, going from most constrained to least constrained, I numbered each
scenario, then cross referenced supporting xsd code:

(1) Restrict to specific namespace(s), strict processing.  
    Only elements from that namespace are valid; 
    the processor must obtain the schema associated with 
    the required namespace, and validate the extended element(s).

(2) Restrict to specific namespace(s), lax processing.  
    Only elements from that namespace are valid; if the processor 
    is able to obtain the schema associated with the required 
    namespace, it will validate the extended element(s).
    If the processor cannot obtain the schema, it skips the 
    validation and the extension point is considered valid.

(3) Restrict to specific namespace(s), skip processing.  
    Only elements from that namespace are valid; 
    but the processor will not obtain the schema associated 
    with the required namespace. It skips the validation
    and the extension point is considered valid.

(4) Allow any namespace, strict processing.  
    Elements from any namespace are valid; the processor 
    must obtain the schema associated with the required 
    namespace, and validate the extended element(s).

(5) Allow any namespace, lax processing.  
    Elements from any namespace are valid; 
    if the processor is able to obtain the schema associated 
    with the specified namespace, it will validate the extended 
    element(s). If the processor cannot obtain the schema, it 
    skips the validation and the extension point is 
    considered valid.

(6) Allow any namespace, skip processing.  
    Elements from any namespace are valid. The processor will 
    not obtain the schema associated with the specified namespace. 
    It skips the validation and the extension point is 
    considered valid.

<!--
matrix to illustrate degrees to which an extension point may be constrained
(untested)
-->

<!-- most constrained, restricted to one namespace, strict processContents:
(1) 
(note: more namespaces could be added, space delimited)
<xsd:any namespace="http://www.w3.org/1999/xhtml"; 
         processContents="strict"
         minOccurs="0" maxOccurs="unbounded"/>
-->

<!-- medium constrained, restricted to one namespace, lax processContents:
(2)
<xsd:any namespace="http://www.w3.org/1999/xhtml"; 
         processContents="lax" 
         minOccurs="0" maxOccurs="unbounded"/>
-->

<!-- least constrained, restricted to one namespace, skip processContents:
(3)
<xsd:any namespace="http://www.w3.org/1999/xhtml"; 
         processContents="skip" 
         minOccurs="0" maxOccurs="unbounded"/>
-->

<!-- or not restricting namespace -->

<!-- most constrained, unrestricted namespace, strict processContents:
(4)
<xsd:any namespace="##other" 
         processContents="strict"
         minOccurs="0" maxOccurs="unbounded"/>
-->

<!-- medium constrained:
(5)
<xsd:any namespace="##other" 
         processContents="lax" 
         minOccurs="0" maxOccurs="unbounded"/>
-->

<!-- least constrained:
(6)
<xsd:any namespace="##other" 
         processContents="skip" 
         minOccurs="0" maxOccurs="unbounded"/>
-->



-----Original Message-----
From: tony.jewtushenko@oracle.com [mailto:tony.jewtushenko@oracle.com] 
Sent: Monday, July 19, 2004 10:16 AM
To: xliff@lists.oasis-open.org 
Subject: [xliff] Groups - XLIFF TC Monthly Teleconference modified



XLIFF TC Monthly Teleconference has been modified by Tony Jewtushenko
(tony.jewtushenko@oracle.com).

Date:  Tuesday, 20 July 2004
Time:  04:00pm - 05:00pm Greenwich Mean Time

- snip -

   i. HTML / RTF: 
      Update: http://www.oasisopen.org/archives/xliff/200404/msg00019.html 
      Major issue to be resolved is whether or not we can extend at Source
and Target.  Review the ballot results on extending Source and Target.
Review any additional progress made by Yves.

To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xliff/members/leave_workgroup.php.


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xliff/members/leave_workgroup.php.



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