Re: ISO/IEC JTC1/SC34/WG1 comments about RELAX NG schemas for XForms 1.1

Dear Mohamed and JTC 1/SC 34/WG 1,

Thank you and the group for the detailed comments.

We discussed some of your comments [1] and I am responding to them.
For others, I've been asked by the Forms WG to investigate and respond later.
We look forward to further help after the next revision of the schemas.

I have additionally added Markus Gylling (not a Forms WG member) to the CC list of this message, in case he wishes to review my comments separately.

More detailed comments are inline below.

Thank you,
Leigh.

[1] http://lists.w3.org/Archives/Public/public-forms/2010Jan/att-0003/2010-01-06.html#topic5



    From: Innovimax SARL <innovimax@gmail.com>
    Date: Fri, 25 Dec 2009 23:57:50 +0100
    Message-ID: <546c6c1c0912251457pff7abccn4c8f4c15534f8e3d@mail.gmail.com>
    To: www-forms-editor@w3.org
    Cc: dsdl-discuss <dsdl-discuss@dsdl.org>, Jirka Kosek <jirka@kosek.cz>
    Cc: "MURATA Makoto (FAMILY Given)" <EB2M-MRT@asahi-net.or.jp>
    Cc: Alex Brown <alexb@griffinbrown.co.uk>, chairs@w3.org
    
    Dear,
    
    Please find those comments about Relax NG schemas for XForms 1.1 as a
    liaison from SC 34 to W3C
    
    Don't hesitate to ask us any further help on the technologies SC 34 is
    promoting :
    * DSDL family : http://dsdl.org/

    ** Relax NG
    ** Schematron
    ** NVDL
    ** DTLL
    ** DSRL
    ** CREPDL
    * Document format
    ** OOXML
    ** ODF
    
    Best wishes
    
    Mohamed ZERGAOUI on behalf of JTC 1/SC 34/WG 1
    
    
    * The main XForms schema is without namespace and second schema file
    is used for "including" elements into proper XForms namespace
    
    This is so called "chameleon" approach for schema design. It is useful
    when it is expected to use the same set of elements in several
    vocabularies each using distinct namespace. But there is no provision
    for using different then XForms namespace in XForms 1.1
    Recommendation.
    
    We are aware that XHTML 2.0 draft used XForm in this way, but it seems
    that W3C has discontinued XHTML 2.0 efforts. We therefore suggest to
    provide only one schema which will explicitly define all elements in
    the XForms namespace. If "chameleon" approach is necessary for reasons
    we don't see this situation should be cleraly described in the schema
    comments so users of schemas are not confused and know which schema
    when to use.
    
Namespaces are not significant to the XForms application. We structured the RelaxNG schema in these two parts as a convenience for those who might profile our XForms 1.1.  An upcoming revision of the Relax NG schema for XForms 1.1 will make it clearer which features of host language
integration depend on namespaces (for example, XForms-namespaced attributes) and which are independent.

We have received reports of language integrations which are independent of the XForms namespace, and while we do not publish the XForms 1.1 Recommendation without a namespace, we believe that a modular schema which facilitates profiling will ultimately improve adoption for XForms.

By the way, we don't expect that all integrations of XForms into host languages will be W3C Recommendations.  ODF, for example, profiles XForms and uses only the XForms model (at least in current versions), and it is not a W3C Recommendation.

    * Definition of extension element (§3.4.1) is missing in the schema
    
    The extension element is described in prose and it is present in W3C
    XML Schema for XForms but it is not present in RELAX NG version of
    schema.
    
We agree, and already noted noted this.  The XSD version, by the way, defines the extension element but does not allow it in the content models of any XForms elements.  Thus the XSD is erroneous as well, and will be corrected.

    * There is no start pattern defined
    
    XForms are usually placed into a host language so provided schema is
    just building block for composition of compound document schema. This
    should be stressed in comments so users are not confused by fact that
    provided schemas are not valid and working itself.

We agree.  An upcoming publication will provide at least a sample language integration.
    
    Moreover it would be better to add elements model, group, repeat,
    switch, input, secret, textarea, output, upload, range, trigger,
    submit, select and select1 as possible start elements to allow
    invocation of the XForms RELAX NG schema from NVDL script.

We will investigate NVDL at a later date; our resolution to provide RelaxNG for XForms 1.1 did not cover NVDL, and WG members do not have experience with it.  We would welcome comments or examples.
    
    * Individual schemas are not referencable by URI
    
    RELAX NG schemas are available in a ZIP file for download. There is
    no stable URI which can be used for referencing schemas. Please note
    that having such persistent URIs for schema doesn't mean that
    validators are going to fetch schemas from this location. Many tools
    have integrated support for XML Catalogs which can redirect requests
    to local copy of resource. Providing stable URI for resource like
    schema is perfectly aligned with Architecture of the World Wide Web
    (see http://www.w3.org/TR/webarch/)

We agree that there should be a location for the schema, but the location was not available at the time of Recommendation publication. We plan to create a separate document for this purpose, perhaps with a host language integration.  As noted above, the current RelaxNG schema is aimed at host language integrators, and is not usable standalone, so the need for a referencable copy is not great.

    
    * Syntax error in xforms-nons-11.rnc
    The last line of definition of pattern xforms.ActionName should be
    
        | (xsd:NMTOKEN - (xsd:NMTOKEN { pattern = "^xforms-.*" }))
                                                        |
    
    instead of
    
        | xsd:NMTOKEN - (xsd:NMTOKEN { pattern = "^xforms-.*" })
    
    This bug was caused by Trang schema converter. WG1 will report this
    problem upstream to Trang developers so tool is fixed for future use.
    
We will fix this in an upcoming version.  Thank you, and Makoto Murata separately, for pointing this out. Future versions will likely be maintained in RNC and converted to XML by trang.  Please let us know if you see any problems with this approach.

    * Improper usage of ^ in regular expression

In the upcoming draft, I find only one pattern which begins with "^", namely the one you list.
Does this mean we should do this?
  (xsd:NMTOKEN - (xsd:NMTOKEN { pattern = "xforms-.*" }))
If so, please let us know.
    
    Patterns in RELAX NG are always matched against complete string so it
    is incorrect to use ^ at the start of regular expression.
    
    * Misuse of combine="interleave" (&= in compact syntax)
    
    The use of &= is recommended only when you combine different
    define statements in different schema modules. Moreover the XForms
    schema does not need to use combine as there are no multiple
    occurences of the same named pattern.
    
    &= should be changed to = in compact syntax, and combine="interleave"
    should be removed from XML version of the schema.
    
Host language integration add content to these patterns.  When we publish the sample host language integration, would your group be so kind as to re-examine this comment and see if we are then using &= correctly?

    * group, repeat, case, label, help, hint, alert and message elements
    allow foreign content but this is not reflected in the schema

    Interleave content models of these elements with anyForeignElement or create
    named pattern which can be overriden by user integrating XForms schema
    into a host language.
    
We agree.  Some of these issues are addressed by the host language integration, and others by bug fixes.  Again, please check our work at the
next revision, if you would be so kind.
    
    The following is an example definition of anyForeignElement (it is
    expecting that xf prefix is bound to the XForms namespace).
    
    anyForeignElement = element * - xf:* { anyAttribute*, anyForeignElement* }
    anyAttribute = attribute * { text }
    
    * Change IDREF datatype to token
    As there are no attributes with type ID defined in the schema there is
    nothing to which IDREF can point. This wíll result in unresolved
    references during validation.

The burden is on host language integration to declare ID attributes. If XForms declared @id to be xsd:ID, it might conflict with a similar definition in the host language.  Or, if the host language each used a different attribute for ID, then there would be two possible attributes for declaring ID, again an unfortunate situation.

I should note that xml:id was first proposed by Stevem Pemberton on November 1, 2002 at an XForms Face-to-Face meeting at Netscape in San
Diego, precisely for the purpose of solving this issue. Unfortunately, RelaxNG does not properly handle xml:id (see
http://blog.jclark.com/2009/01/relax-ng-and-xmlid.html ) and so we are unable to rely on it here.

    
    -- 
    Innovimax SARL
    Consulting, Training & XML Development
    9, impasse des Orteaux
    75020 Paris
    Tel : +33 9 52 475787
    Fax : +33 1 4356 1746
    http://www.innovimax.fr

    RCS Paris 488.018.631
    SARL au capital de 10.000 €

Again, thank you for your comments.  They are helpful to us.

Leigh.

Received on Tuesday, 12 January 2010 21:07:33 UTC