Thanks, Yves & Bryan.
> 1-- ...The main
> modification is the fix of the definition
of the type for the 'purpose'
> attribute. Since it was impossible to use
a list to mix pre-define and
> user-defined values, Bryan worked on a
regular expression, so 'purpose' is
> now defined through a pattern and it
work with XSV, XMLSpy and MS XSD
> Validator (not a small achievement:
Thanks Bryan).
When I suggested purpose I did not intend that both
extended and enumerated values would be mixed. I guess we might have to
account for that. I would, however, accept a non-mixed definition. Thus,
enumerate the stated values or allow a single extended value. That way the
schema woud be much more understandable.
> 3-- One little (but important) point about the extension points in
the
> schema: They are currently set as '##other', which means "Any
well-formed
> XML that is not from the target namespace of the type being
defined" (thus,
> non XLIFF). Christian remineded me that a while back,
there was a discussion
> about replacing this by '##any', which means "Any
well-formed XML from any
> namespace" (thus, including XLIFF itself). The
rational was that we may want
> give users a possiblity to use XLIFF data
categories in a non-standard
> context.
Can you or Christian provide an example of why this is needed?
> 4-- As per yesterday discussion it seems that some of us assume
the
> 'context-type' attribute can take several values (like 'purpose').
There is
> no information about this is the current specifications and the
current
> schema doesn't allow this. If it's the case, the schema needs to
be adapted
> and use a pattern like for 'purpose'. When reading the
specifications keep
> in mind that if the description of the attribute
does not mention the values
> can be used in combination it means the
schema does not allow combination.
> Let me know where else there is a
discripancy like for 'context-type'.
I'm okay with single values. In fact, I prefer it. I know of no other
enumerated set that should allow this mix.
cheers,
john
