[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xliff][follow-up] FW: Degrees of constraint
Hi Mat,
You wrote:
> Don't know if this is workable though
> Any Thoughts?
Wow. I like your idea. I think it's quite workable.
We'd just need to do something along these lines;
Change this:
<xsd:complexType name="ElemType_target" mixed="true">
<xsd:group ref="xlf:ElemGroup_TextContent" minOccurs="0"
maxOccurs="unbounded"/>
<xsd:attribute name="state" type="xlf:AttrType_state"
use="optional"/>
<xsd:attribute name="state-qualifier"
type="xlf:AttrType_state-qualifier"
use="optional"/>
<xsd:attribute name="phase-name" type="xsd:NMTOKEN"
use="optional"/>
<xsd:attribute ref="xml:lang" use="optional"/>
<xsd:attribute name="ts" type="xsd:string" use="optional"/>
<xsd:attribute name="restype" type="xlf:AttrType_restype"
use="optional"/>
<xsd:attribute name="resname" type="xsd:string"
use="optional"/>
<xsd:attribute name="coord" type="xlf:AttrType_Coordinates"
use="optional"/>
<xsd:attribute name="font" type="xsd:string"
use="optional"/>
<xsd:attribute name="css-style" type="xsd:string"
use="optional"/>
<xsd:attribute name="style" type="xsd:NMTOKEN"
use="optional"/>
<xsd:attribute name="exstyle" type="xsd:NMTOKEN"
use="optional"/>
<xsd:anyAttribute namespace="##any" processContents="lax"/>
</xsd:complexType>
to this:
<xsd:complexType name="ElemType_target" mixed="true">
<xsd:choice>
<xsd:group ref="xlf:ElemGroup_TextContent" minOccurs="0"
maxOccurs="unbounded"/>
<!-- add Mat's new element -->
<xsd:element ref="xlf:Extend" minOccurs="0"
maxOccurs="unbounded"/>
</xsd:choice>
<xsd:attribute name="state" type="xlf:AttrType_state"
use="optional"/>
<xsd:attribute name="state-qualifier"
type="xlf:AttrType_state-qualifier"
use="optional"/>
<xsd:attribute name="phase-name" type="xsd:NMTOKEN"
use="optional"/>
<xsd:attribute ref="xml:lang" use="optional"/>
<xsd:attribute name="ts" type="xsd:string" use="optional"/>
<xsd:attribute name="restype" type="xlf:AttrType_restype"
use="optional"/>
<xsd:attribute name="resname" type="xsd:string"
use="optional"/>
<xsd:attribute name="coord" type="xlf:AttrType_Coordinates"
use="optional"/>
<xsd:attribute name="font" type="xsd:string"
use="optional"/>
<xsd:attribute name="css-style" type="xsd:string"
use="optional"/>
<xsd:attribute name="style" type="xsd:NMTOKEN"
use="optional"/>
<xsd:attribute name="exstyle" type="xsd:NMTOKEN"
use="optional"/>
<xsd:anyAttribute namespace="##any" processContents="lax"/>
</xsd:complexType>
And add this:
<xsd:element name="Extend">
<!-- define Mat's new element -->
<xsd:complexType>
<xsd:sequence maxOccurs="unbounded">
<!-- list of valid namespaces could be added here, space delimited -->
<xsd:any
namespace="http://www.w3.org/1999/xhtml";
processContents="lax" />
</xsd:sequence>
<xsd:attribute name="state"
type="xlf:AttrType_state" use="optional"/>
</xsd:complexType>
</xsd:element>
And Bob's your uncle.
I think this is a nice solution. We could close the list of namespaces in
<Extend's content model to whatever set we think is reasonable. And we
could still fine-tune the degree of constraint with the "processContents"
attribute.
-----Original Message-----
From: Matthew Lovatt [mailto:matthew.lovatt@oracle.com]
Sent: Tuesday, July 27, 2004 1:14 AM
To: Schnabel, Bryan S; xliff@lists.oasis-open.org
Subject: Re: [xliff][follow-up] FW: Degrees of constraint
Hi All
We may be able to tackle Bryan's Second point with a new element in XLIFF
Here is the idea
We do not include an extension point in the source and target directly, but
we allow a new XLIFF element, call it <Extend> (for the sake of this
discussion) to be a child of source and target.
The Extend element contains the extension point.
The Extend element can contain the state attribute
So Bryans example becomes:
<Target>Our guests can appease their spirit of adventure
and <Extend state="final"><xhtml:i>itchy feet </xhtml:i></Extend>
by exploring the various islands of our small archipelago.
</Target>
We may add extra attributes from other elements to this new element as
required.
Adding a new element means opening the spec again, but we have to do that
anyway to include the proposed new extension points.
We could of course keep the extension points in source and target, and use
the extension point directly unless we want to override the behaviour of
the extension.
However, The new element may have useful possibilities for "controlling"the
content of the extension point.
For example, We may specify the name space of the extension as an attribute
of the Extend element. If this attribute is a closed list, we can constrain
the namespaces in the document. Don't know if this is workable though
Any Thoughts?
Mat
----- Original Message -----
From: <bryan.s.schnabel@exgate.tek.com>
To: <xliff@lists.oasis-open.org>
Sent: Monday, July 26, 2004 10:16 PM
Subject: RE: [xliff][follow-up] FW: Degrees of constraint
> Hello all,
>
> This is a follow up concerning two topics that arose at the last TC
meeting.
>
> - topic 1:
> DEGREES OF CONSTRAINT FOR EXTENDED
> ATTRIBUTES on <Source and <Target
>
> I took an action item to clarify this in our last meeting. The question
> arose about if and how the various degrees of constraint could apply to
> extension points for attributes on Source and Target. I said the same
> degrees were achievable, just like they are for extension points for
> elements, and that I'd volunteer to document the precise syntax. I
updated
> the matrix at the bottom of the attached note to include degrees of
> constraint for extension points for attributes.
>
> - topic 2:
> SIGNALING TRANSATION INSTRUCTIONS (YES or NO)
> FOR EXTENDED ELEMENTS in <Source and <Target
>
> The issue is this. Extended elements in <Source and <Target in some case
> might be intended to be translated, and in some cases might not be
intended
> to be translated. How can we signal this?
>
> I can think of two ways, but they're each very impacted by the strictness
> setting on the "processContents" attribute in the XLIFF schema. Suppose
> allow an extension point in <Target, and constrain it to the XHTML
> namespace. And suppose we want to make use of this extension point, like
> this:
>
> <Target>Our guests can appease their spirit of adventure
> and <xhtml:i>itchy feet </xhtml:i>
> by exploring the various islands of our small archipelago.
> </Target>
>
> We could stick a random attribute on the extended element like this:
>
> <Target>Our guests can appease their spirit of adventure
> and <xhtml:i xlate="no">itchy feet </xhtml:i>
> by exploring the various islands of our small archipelago.
> </Target>
>
> The problem is, the XHTML schema does not have an "xlate" attribute for
the
> <i element. So if the "processContents" attribute in the XLIFF schema was
> set to "strict," the validation would fail. And if it was set to "lax,"
the
> validation would fail in cases where the XHTML schema was resolved, and
> would succeed in cases where the schema was absent. The only way this
would
> work 100% of the time would be if we set the "processContents" to "skip."
> However, this would make it really easy to "fool" the processor with bogus
> XHTML elements and attributes.
>
> So then I thought, what about establishing an XLIFF namespace, then use an
> XLIFF attribute with a valid value (per the XLIFF schema)?
>
> <Target>Our guests can appease their spirit of adventure
> and <xhtml:i xlf:state="final">itchy feet </xhtml:i>
> by exploring the various islands of our small archipelago.
> </Target>
>
> But that's not much better. While "final" is a valid field for the
"state"
> attribute, the problem is the <i element in the XHTML schema does not
allow
> an extension point. So the this approach would also require the
> "processContents" attribute to be set to "skip" as well, for the same
> reasons as above.
>
> I can think of no other way to allow extension points on <Source and
> <Target, and constrain them to specific namespaces, in any meaningful way
> (so in my mind, unless there's a way I'm just not seeing, I guess item (5)
> from the original list below still seems like the most useful way).
>
> Thanks,
>
> Bryan
>
>
> -----Original Message-----
> . . .
> -----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
>
>
> . . .
>
> (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"/>
>
> <xsd:anyAttribute namespace="http://www.w3.org/1999/xhtml";
> processContents="strict" />
> -->
>
> <!-- medium constrained, restricted to one namespace, lax processContents:
> (2)
> <xsd:any namespace="http://www.w3.org/1999/xhtml";
> processContents="lax"
> minOccurs="0" maxOccurs="unbounded"/>
>
> <xsd:anyAttribute namespace="http://www.w3.org/1999/xhtml";
> processContents="lax" />
> -->
>
> <!-- least constrained, restricted to one namespace, skip processContents:
> (3)
> <xsd:any namespace="http://www.w3.org/1999/xhtml";
> processContents="skip"
> minOccurs="0" maxOccurs="unbounded"/>
>
> <xsd:anyAttribute namespace="http://www.w3.org/1999/xhtml";
> processContents="skip" />
> -->
>
> <!-- or not restricting namespace -->
>
> <!-- most constrained, unrestricted namespace, strict processContents:
> (4)
> <xsd:any namespace="##other"
> processContents="strict"
> minOccurs="0" maxOccurs="unbounded"/>
>
> <xsd:anyAttribute namespace="##other"
> processContents="strict" />
> -->
>
> <!-- medium constrained:
> (5)
> <xsd:any namespace="##other"
> processContents="lax"
> minOccurs="0" maxOccurs="unbounded"/>
>
> <xsd:anyAttribute namespace="##other"
> processContents="lax" />
> -->
>
> <!-- least constrained:
> (6)
> <xsd:any namespace="##other"
> processContents="skip"
> minOccurs="0" maxOccurs="unbounded"/>
>
> <xsd:anyAttribute namespace="##other"
> processContents="skip" />
> -->
>
> 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.p
hp.
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]