Re: LC-215 - Easy Add-ins (i18n Comment on XML Schema Last Call Working Draft)

Hello Martin :-),

Many thanks for following up on this. Unfortunately, your mail does
not give us enough information to decide whether we are satisfied
with the Schema WG decision. We need more detailed information,
and in particular some examples, to make such a decision.

The part of our mail that is now registered as LC-215 contains
various various examples and proposals, and if you could work
out one of these, I guess that would be a good starting point.

More comments below.

At 00/09/21 12:25 -0400, Martin Gudgin wrote:
>Dear I18N Working Group
>
>The W3C XML Schema Working Group has spent the last several months
>working through the comments received from the public on the last-call
>draft of the XML Schema specification.  We thank you for the comments
>you made on our specification during our last-call comment period, and
>want to make sure you know that all comments received during the
>last-call comment period have been recorded in our last-call issues
>list (http://www.w3.org/2000/05/12-xmlschema-lcissues).
>
>Among other issues, you raised the point registered as issue LC-215, Easy
>add-ins.

The relationship of this to LC-216 should also be noted. Any ideas
about what the WG plans to do on that one?


>The Working Group discussed this issue and came to the following
>conclusions;
>
>1    We agree that this is, in principle, a reasonable goal.

Thanks.


>We believe
>that the existing refinement mechanism does make it possible to add
>attributes or subelements as described.

If you believe, that doesn't help us. If you know, and can show us
how, that would be helpful.


>2    The new 'redefine' mechanism[1] may make such changes easier in some or
>most cases.

Do you mean "6.2.2 Including modified component definitions"
http://www.w3.org/XML/Group/xmlschema-current/structures/structures.html#mod 
ify-schema

It looks indeed like this might help, but we need more certainty than
that. As an example, assume a traditional HTML-like document type.
If this is well structured, it will somewhere have an 'inline'
equivalence class (if that term is still used in the current draft).
Can you show an example where:

- An additional element is added to 'inline'?
- An additional attribute is added to 'inline'?

Also, can you help us figure out whether the result of these additions
would be in the original namespace or a new one, or whether e.g.
only the new element/attribute would be in the new namespace?


>3     A generic or fairly generic XSLT stylesheet could be written
>to automate the generation of types containing extra attributes, elements or
>sets of the same.

It looks like that's not what we want. I.e. to take the above case,
if there is a concept of 'inline' in the schema, and the additions
are conceptually meant to go to 'inline', this should not have to
be done by adding things to the elements derived from inline,
neither by hand nor somehow automatically.


>The XML Schema Working Group would also like to invite the i18n WG to
>participate in the inter-WG task force for a common library of complex
>types. Alternatively, if the i18n WG would prefer to create a separate
>library of i18n-related types, we are willing to collaborate with the i18n
>WG on that if they prefer.

I think the idea of a common library of complex types is very good.
We thought about that already several times, but didn't get around
to do any actual work yet. Within the bounds of our resources, we
would definitely be interested in participating.

However, we do not think that this helps to satisfy our concerns
as expressed in LC-215, because a common library will only be
a long term solution, not a short term solution, and because
it won't remove the need for additions totally.


>It would be helpful to us to know whether you are satisfied with the
>decision taken by the WG on this issue, or wish your dissent from the
>WG's decision to be recorded for consideration by the Director of
>the W3C.

We want to know better how things would actually work, so that we can
understand whether we agree or disagree.

I hope you can help us with that.


Regards,   Martin.

Received on Wednesday, 27 September 2000 04:00:13 UTC