OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng-comment message

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


Subject: Re: comments relax-ng 0.9


Thanks for your comments.  The following is my personal response.  The TC as
a whole may wish to respond differently.

1. The semantics are properly conserved because <define>s containing
multiple child elements will be normalized before they are substituted.  For
example,

<define name="example">
  <element name="firstName"><text/></element>
  <element name="lastName"><text/></element>
</define>

wil be transformed into

<define name="example">
  <group>
    <element name="firstName"><text/></element>
    <element name="lastName"><text/></element>\
  </group>
</define>

See section 4.12 of the spec.

2. You can achieve the effect of global="true" by using:

<attribute>
  <name>some-global-att</name>
</attribute>

instead of

<attribute name="some-global-att" global="true"/>

3. Keys are certainly useful, but I believe keys are better dealt with by a
separate specification and a separate language. It's better to have small,
modular specifications that can be combined as needed, rather than one big,
monolithic specification.  I hope the RELAX NG TC will address that at some
point in the future. However, I think standardization at this point would be
premature. It's still an area of active research. While the XML Schema
facility is powerful, it has significant flaws.  I think it is better to
wait a little and do it right.


----- Original Message -----
From: "Berthold Daum" <bdaum@online.de>
To: <relax-ng-comment@lists.oasis-open.org>
Sent: Sunday, September 30, 2001 7:16 PM
Subject: comments relax-ng 0.9


Hi,

I have a few points of concern regarding the Relax-NG 0.9 specifications:

1. Some operations seem not to conserve semantics. For example, given the
pattern

<define name="example">
  <element name="firstName"><text/></element>
  <element name="lastName"><text/></element>
</define>

When we insert this pattern into some contexts, the intended semantics could
be destroyed:

<choice>
  <ref name="example">
</choice>

matches only with instances that have either a firstName or a lastName.

<interleave>
  <ref name="example>
</interleave>

looses the intended order of elements. This is even true when the pattern is
defined with a <group> clause.

While all the above operations are completely correct in terms of pattern
substitution, they could
prove dangerous. Schema authors may with this pattern intuitively associate
similar semantics as
given by

<element name="name">
  <element name="firstName"><text/></element>
  <element name="lastName"><text/></element>
</element>

Here the definition of a sequence of child elements has the implicit meaning
of an ordered sequence, a
meaning that could be associated with the above pattern definition by
analogy.

To my opinion, schema validators should give a warning when such a pattern
is referenced in a way as
shown in the examples above.

2. global="true"

I think this functionality is required, especially when referencing an
external pattern with

<externalRef href="chameleon.rng" ns="http://www.example.org"/>

The global attribute would allow to cast also the attributes of such a
"chameleon" pattern into the
specified namespace.
Maybe the name of the attribute should be revised though, for example,
something like "parentNs".

3. Cross references

I think, in this point Relax-NG falls back behind XML Schema. The ability to
define multi-field keys
and key references is, for example, required when we want to serialize
databases into XML.

4. Brilliant. Love it!


Berthold Daum
bdaum industrial communications
bdaum@online.de






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


Powered by eList eXpress LLC