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

 


Help: OASIS Mailing Lists Help | MarkMail Help

relax-ng message

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


Subject: Updated issue list



updated to reflect changes made in 2001/07/19 conference call.


regards,
--
Kohsuke KAWAGUCHI                          +1 650 786 0721
Sun Microsystems                   kohsuke.kawaguchi@sun.com

issues.xml

Title: RELAX NG Issues List

RELAX NG Issues List

Version $Id: issues.xml,v 1.30 2001-07-23 12:32:41-07 bear Exp bear $

Table of Contents

Remaining Issues

32. Context information for datatype libraries
40. restriction of <interleave>
45. Further restriction for the <oneOrMore> pattern
47. processing of @datatypeLibrary and @ns
54. a spec for the common annotation
55. external grammar reference mechanism
56. key/keyref inside <list>

All Issues

1. Should empty elements allow whitespace?
2. Name of "difference" element
3. xml:base support
4. add wildcard pattern
5. syntax of "global" attribute on "attribute" element
6. Split "include" element to two different elements
7. Name of "grammar" element
8. Parameterized patterns
9. List of simple datatypes
10. Versioning
11. Repeat M-N times
12. Syntax of parent attribute on ref element
13. Allow difference of patterns
14. ID/IDREF problem
15. Drop concur
16. Add "exclusion" pattern
17. name of the new language
18. restriction on use of string/data in pattern
19. prohibits attribute/element pattern in attribute pattern
20. redefinitions and order-significance
21. prohibiting duplicate attributes
22. Overlapping with XML Schema Part 2
23. Prohibiting nested grammars
24. Datatype and Identity Constraint
25. Namespace URI of RELAX NG
26. Restrict patterns to the regular language
27. Use of QNames
28. Introduce <list> pattern to replace <oneOrMoreToken>/<zeroOrMoreToken>
29. Scope of key/keyref symbol spaces
30. Redefinition without original
31. Multiple definitions in the same file
32. Context information for datatype libraries
33. <element> and <attribute> in <list>
34. allow non-whiteSpace delimiter for <list>
35. renaming the "name" attribute.
36. Allowing multiple operands for <not>
37. Resolution of the default namespace for XSD's QName datatype
38. Allowing <list> in <list>
39. simpler syntax for name class
40. restriction of <interleave>
41. adding the pattern facet to <text/> and <mixed/>
42. <except/> pattern
43. adding <key>/<keyref> element instead of @key/@keyref
44. drop @name from <start>
45. Further restriction for the <oneOrMore> pattern
46. fragment identifier for href attribute
47. processing of @datatypeLibrary and @ns
48. <eleemnt name="..."/> and <attribute name="..."/>
49. nsName using prefix
50. Syntax sugar for optional attributes
51. implicit grouping in <start>
52. overriding attribute
53. empty strings as keys and keyrefs
54. a spec for the common annotation
55. external grammar reference mechanism
56. key/keyref inside <list>

Introduction

The new issue process is now enforced. A issue can be raised and added to the issue list only if (1) at least three members are agreed to consider it an issue, or (2) it is a supplementary thing related to the previous decision of TC and need to be clarified.

Issues

1. whiteSpaceInEmpty: Should empty elements allow whitespace?

Originator: jjc@jclark.com Status: resolved

Description

original post

Proposed Resolution

proposals are also made in the original post.

clarification made by John Cowan.

Actual Resolution

Voted unanimously to resolve this issue by allowing elements with no declared children tp have whitespace.

2. differenceName: Name of "difference" element

Originator: jjc@jclark.com Status: resolved

Description

The original post

Proposed Resolution

"except" and "butNot" by jjc. TC is open to other suggestions.

Actual Resolution

TC's general feeling was, there is no good reason to change it. On 5/31/2001, TC has decided to close this issue without any action until someone bring up a new material.

3. xmlBase: xml:base support

Originator: jjc@jclark.com Status: resolved

Description

The original post

Proposed Resolution

any decision was postponed until xml:base gets REC status.

Actual Resolution

In 2001/06/28, TC decided that RELAX NG processors should honor xml:base.

4. wildcardPattern: add wildcard pattern

Originator: jjc@jclark.com Status: resolved

Description

The original post

Proposed Resolution

the original post suggests to introduce syntax sugars to match frequently used wildcard patterns. Namely,

  1. Add a pattern that matches a single element, regardless of its name, attributes and children.
  2. Add a pattern that matches anything: any attributes and any content.

Some concerns that whether this was important enough to be worth a special syntactic abbreviation. No conclusion was reached.

Actual Resolution

On 5/31/2001, TC decided to drop this feature for ver.1. Reasons that mentioned are (1) it's not a good practice so it's good to keep it slightly cumbersome, (2) we don't lose the expressiveness of RELAX NG, (3) it's less frequently used, (4) and adding it at the later moment is easier than dropping it at the later moment.

5. globalAttrName: syntax of "global" attribute on "attribute" element

Originator: jjc@jclark.com Status: resolved

Description

The original post

Proposed Resolution

jjc suggests form="prefixed|unprefixed" or form="qualified|unqualified" (the same as XML Schema).

Just as a possibility, jjc also mentioned to split <attribute> to two different elements, just like we did for the parent attribute of the <ref> element.

Actual Resolution

On 5/31/2001, TC decided to close this issue with no-action-required.

James reported that the semantics of the global attribute can be achieved by using the name element, instead of the name attribute. So TC has decided to remove the global attribute from the attribute pattern (7/12/2001).

6. splitInclude: Split "include" element to two different elements

Originator: jjc@jclark.com Status: resolved

Description

The original post

Circumstance

On April,4,2001 telcon, most people felt it was desirable to split, if a good pair of replacement names could be found.

Actual Resolution

On 5/31/2001, pattern-level inclusion is renamed to <externalRef>.

7. grammarName: Name of "grammar" element

Originator: jjc@jclark.com Status: resolved

Description

The original post.

Actual Resolution

Murata-san reported that RELAX Namespace will use <framework> for its root element. Therefore, RELAX NG will keep using the name <grammar>.

8. parameterizedPattern: Parameterized patterns

Originator: jjc@jclark.com Status: resolved

Description

The original post.

Proposed Resolution

From the beginning, jjc alludes to taking no action with this issue.

Actual Resolution

Voted unanimously not to include them in the first version (Apr,4,2001 telcon). The feeling was that this was on the wrong side of the 80/20 divide for the first version.

9. builtinList: List of simple datatypes

Originator: jjc@jclark.com Status: resolved

Description

The original post.

Circumstance

This issue is merged into the "datatype and identity constraint" issue.

Actual Resolution

Decided to introduce <oneOrMoreToken> and <zeroOrMoreToken> patterns to produce list.

10. versioning: Versioning

Originator: jjc@jclark.com Status: resolved

Description

The original post.

Proposed Resolution

(a) Put a version in the RELAX NG namespace URI (by jjc)

(b) Use a version attribute on the root element (by jjc)

Interactions and Input

Input from Eric van der Vlist obtains:

He suggests to have both (a) and (b)

Input from John Cowan obtains:

He suggests to use FPI (kk: kind of URN?)

Actual Resolution

In the 5/3 telecon, we've decided to use a proposal (a). See the detail of this proposal

11. MNrepeat: Repeat M-N times

Originator: jjc@jclark.com Status: resolved

Description

The original post.

Interactions and Input

Input from Josh Lubell obtains:

He wants to have this because of his own experiences

Input from Kohsuke Kawaguchi obtains:

He suggests that this feature can be provided outside of the core spec (as a pre-processor like tool).

TC is still not convinved whether this feature is imporant enough to be added.

Actual Resolution

The decision is made (but tentatively) to drop this feature from version 1.

12. parentAttrOnRefElem: Syntax of parent attribute on ref element

Originator: jjc@jclark.com Status: resolved

Description

The original post.

Proposed Resolution

James Clark proposed to change attribute name to more sutaible one, but none is suggested by anyone.

John Cowan suggests adding optional "grammar" attribute to "ref" element and thereby introducing the ability to refer to any ancestor grammar.

Actual Resolution

On 5/31/2001, TC decided to use <parentRef name="..."/> instead of <ref name="..." parent="true"/>. So now we have <ref>,<externalRef>, and <parentRef>.

13. diffPattern: Allow difference of patterns

Originator: jjc@jclark.com Status: resolved

Description

The original post.

A comment from Jeni Tennison has re-opened this issue. Here is a quote from his post to relax-ng-comments:


I'd like to be able to restrict the contents of the xs:restriction
element based on its base attribute, but only for certain values. So
if its base attribute is "xs:decimal" then it could contain
xs:totalDigits but if it's "xs:string" then it can't, and so on.
However, if it's not a name in the 'xs' namespace, then I want to
allow any content.

Best would be to exclude all QName values with a particular namespace,
but XMLSchema-datatypes doesn't offer that as a facet (and therefore
RELAX NG doesn't have it as a parameter). I don't want to use the
'pattern' parameter to test the names because that would undermine the
namespace awareness of the schema. I thought I could create a pattern
that didn't match particular enumerated values, but I can't find a way
to do so.  What I'm looking for is something like:

<choice>
   <group>
      <attribute name="foo">
         <value>bar</value>
      </attribute>
      <element name="bar"><empty /></element>
   </group>
   <group>
      <attribute name="foo">
         <!-- not current RELAX NG -->
         <not>
            <value>bar</value>
         </not>
         <!-- /not current RELAX NG -->
      </attribute>
      <element name="baz"><empty /></element>
   </group>
</choice>

This use case would imply that the difference element would be useful
outside name classes as well.

Proposed Resolution

It is easy to implement validators if the use of <difference> p1 p2 </difference> is limited in such a way that both p1 and p2 matches one token and one token only (e.g., <data>, <value>, choices of those things.)

So it looks like a good advancement in the functionality with a very small cost. Do we want to have <difference> in this restricted fashion?

Also, if we add <difference>, then we can (or should) also allow <not> P </not> as a syntax sugar of

<difference><data type="string"/> P </difference>

Actual Resolution

TC has voted not to adopt the functionality (the original proposal of allowing <difference> to any patterns) for ver.1.0. But it is re-opened now.

For the problem pointed out by Jeni Tennison, TC has decided to adopt a new syntax based on James' proposal. A new issue related to this one is opened to further discuss this proposal (2001/06/28).

15. dropConcur: Drop concur

Originator: jjc@jclark.com Status: resolved

Description

The original post.

Proposed Resolution

jjc suggests to remove concur pattern from the spec by various reasons.

Actual Resolution

Voted unanimously to drop concur pattern (Apr,5,2001 telcon).

16. exclusion: Add "exclusion" pattern

Originator: jjc@jclark.com Status: resolved

Description

The original post.

Proposed Resolution

jjc suggests to add a pattern to model a tag-name based exclusion.

Actual Resolution

TC has voted and decided not to include this feature in the first version. TC will revist this issue in the future. (author of this issue list is unaware of when this vote took place.)

17. languageName: name of the new language

Originator: mura034@attglobal.net Status: resolved

Description

What will be the name of the new language? (The original post.)

Proposed Resolution

Various people sugges various names (including, but not limited to, TRELAX, TryRELAX, RELAXED, RELEX, REFLEX, RELAX XML Schema, TREELAX, RELAX 2, EXLAX, etc, etc.

One of the concern is whether we should include "XML Schema" in the name.

Update(May,3rd): jjc suggests "RELAX something" for various reasons (see minutes of May,3rd telecon). In response, "RELAX NG" (next generation, I guess) and RELAX++ are proposed. Other post-fixes are welcome.

Names suggested after the telecon includes URELAX, iRELAX, and TRELAX. The editor feels that RELAX NG establishes some degree of popularity.

Actual Resolution

We will use "RELAX NG" and its pronunciation will be "relaxing."

18. restrictStringUse: restriction on use of string/data in pattern

Originator: mura034@attglobal.net Status: resolved

Description

Some form of constraints on use of <string> or <data> pattern is necessary for validating processor to work correctly. (related posts [1] [2] ).

Proposed Resolution

The current spec already has several restrictions that prevents problematic situations.

Some argues that the current restrictions still have something to be desired.

Actual Resolution

TC decided to adopt the restriction proposed in the post of James Clark (2001/06/21).

19. attrInAttr: prohibits attribute/element pattern in attribute pattern

Originator: mura034@attglobal.net Status: resolved

Description

Currently, RELAX NG allows patterns like

<attribute name="foo"><attribute name="..." /></attribute>

<attribute name="foo"><element name="..." /></attribute>

Should we explicitly prohibits them?

(original posts [1] [2] ).

Circumstance

Those malformed patterns cannot accept anything: any RELAX NG processors can safely replace those malformed patterns by <notAllowed /> without changing semantics.

So at least it doesn't confuse processors.

Proposed Resolution

Murata-san suggests to "implementations SHOULD issue a warning" for a pattern that matches the following condition: that is, <attribute> pattern that "directly or indirectly contain other <attribute> or <element> patterns" after the normalization.

Actual Resolution

In the conference call of 2001/06/14, we voted to make this situation as an error that must be reported by processors. One of the reasons was the lack of good use cases that make use of <attribute>/<element> in <attribute>

20. orderSignificance: redefinitions and order-significance

Originator: jjc@jclark.com Status: resolved

Description

RELAX NG pattern is currently sensitive to the order of <define> element or order of <include> element because of the redefinition capability.

However, this sensitivity can be removed by restricting redefinition to only under <include> element (like XML Schema). But this restriction also limits the expressiveness of RELAX NG.

Should we introduce this restriction to make RELAX NG pattern order-insensitive language? Is this worth the cost of limiting language expressiveness?

( original posts )

Proposed Resolution

  1. The original post proposes to "require that <define> elements that redefine or combine with other definitions should go inside the <include> elements that includes the pattern that contains the original definition."
  2. Another proposal made by jjc.
    • attach a priority to definitions to allow combination without order dependence (like xsl:template).
    • prohibit applying "different kinds of combine for a single pattern".
  3. The proposal #3 by jjc, which is amended a bit.
    • combine="interleave"/"choice" can be used as status quo.
    • combine="group" cannot be used.
    • the functionality that implement the semantics of combine="replace" is introduced in order-insignificant way.

Circumstance

One of the touchstone will be XHTML modularization. kk wrote that the proposal #1 does not work and #2 does with XHTML m12n.

Actual Resolution

The proposal #3 with its amendment is adopted.

21. duplicateAttributes: prohibiting duplicate attributes

Originator: jjc@jclark.com Status: resolved

Description

RELAX NG allows patterns like

<element name="joe">
    <attribute name="foo"> ... </attribtue>
    <attribute name="foo"> ... </attribtue>
</element>
		

Can we prohibit patterns like this? If so, how can we do that?

( the original post )

Proposed Resolution

The GNF normalization can detect such a condition. However, since it is a time-consuming operation, it may not be suitable to mandate the enforcement of this constraint.

Murata-san proposed that "implementations MAY issue warning messages" by using the GNF normalization.

Jjc proposed that for every <group> p1 p2 </group>, "the set of possible attribute names occuring in p1 must be disjoint from those occuring in p2." (The present author believes that the same restriction is necessary for <interleave/>.)

Another proposal made by M-san introduces a new primitive <multipleAttributes> NC P </multipleAttribuets> that has the built-in "zero-or-more" semantics.

Actual Resolution

In the conference call of 2001/06/14, TC has voted to adopt JJC's proposal. See the algorithm.

22. datatypeOverlap: Overlapping with XML Schema Part 2

Originator: mura034@attglobal.net Status: resolved

Description

XML Schema Part 2 has capability to

  1. create union of multiple types.
  2. create list of multiple types.
  3. assign a name to the type and refer to it by name.

But our language is also capable of doing above three.

So if we use XML Schema Part 2 as the only datatype vocabulary, we should consider dropping some of the redundant capability. (That is, restricting choices of <data>s, for example).

( the original post )

Proposed Resolution

jjc suggests to close this with "no-action required" because he wants to keep a distance from XML Schema Part 2.

Actual Resolution

We decided not to use the syntax of W3C XML Schema Part 2 for defining datatypes. Therefore, the overlap no longer exists.

23. nestedGrammar: Prohibiting nested grammars

Originator: mura034@attglobal.net Status: resolved

Description

We currently allow <grammar> elements to be nested. That is, grammar can be used just like any other patterns.

Murata-san wants to prohibit this because it may interfere with future namespace-based modularization (as currently seen in RELAX and XML Schema).

( the original post )

Circumstance

"Namespace-based modularization" means that one module is responsible for one namespace. In my personal opinion (and probably Murata-san's), this is vital for multi-lingual validation, where multiple schema languages cooperates to validate one document.

Murata-san said he is willing to retract this if someone can convince him that nested grammar doesn't possibly interfere with such modularization.

Actual Resolution

Murata-san retracted his objection in 2001/6/7. This issue was then resolved as no-action-required.

24. datatype: Datatype and Identity Constraint

Originator: ??? Status: resolved

Description

This issue is arose by merging several issues.

The first objective was to introduce the identity constraint functionality in our new language. Then we've found that this issue is related to how our language treats datatypes.

Circumstance

It starts with a series of posts by jjc that describes possible features [multipart key] , [typed key] , [scoped key] , [multiple key symbol spaces] , and [keys in element] .

Those posts are about possible features, but how those requirements affect the design is generally unclear. The editor believes that one thing that has developed in telcon is that we don't need any path expression if we abandon multipart keys.

In 5/3 telcon, we've made some degree of consensus about the above requirements (see minutes).

After the telcon, jjc posts his two proposals.

  • "ID/IDREF strawman #1". This proposal is relatively simple, but leaves several problems unresolved. Firstly, key is not typed. So "1" and "01" is considered different even when the type is integer. Secondly, it doesn't work well with anonymous types. Datatype libraries have to provide a capability to test the equality of two types.
  • "ID/IDREF strawman #2". This is also a relatively simple proposal. But it still has several problems. Firstly, it doesn't work well with anonymous types. This time, you have to use built-in types.

So now it is discovered that without greater involvement to datatypes, we can't use anonymous (or user-defined) types in key/keyref. This discovery leads to another proposal from jjc.

  • "datatypes #1". This post proposes how to declare new datatypes under the control of our language and how to declare key/keyref constraint.

    What's important here is "under the control of our language". RELAX NG allows datatype library(DTLIB) to use its own syntax to declare new types. But in this proposal, every DTLIB is required to use the syntax of this proposal (to make type equivalence test possible).

  • Datatypes #2 ("the proposal of the day"). Roughly speaking, this is a simplified version of "datatypes #1", which "I(jjc) hope will be able to command consensus."

    The difference with the previous proposal is that this one doesn't have the concept of "derivation". That means you can't add facets to your type once you defined it.

Kohsuke KAWAGUCHI also proposes the most simple version.

Actual Resolution

The above "datatypes #2" proposal is adopted. We use the following syntax to define enumeration:

<choice>
  <token type="xsd:integer"> 5 </token>
  <token type="xsd:integer"> 2 </token>
</choice>

And the following syntax to define a datatype:

<data type="xsd:integer">
  <param name="minInclusive"> 5 </param>
  <param name="maxExclusive"> 8 </param>
</data>

For many other details, see the minutes of the conference call. (Not available at this moment.)

25. nsURI: Namespace URI of RELAX NG

Originator: jjc Status: resolved

Description

We need a namespace URI for the new language.

Proposed Resolution

jjc suggests "http://relaxng.org/ns/m.n" where m.n is the version number.

M-san suggets "http://relaxng.org/ns/something/m.n" so that we can accommodate related namespace URIs. For "something", jjc suggests "structure".

Circumstance

In the 5/31/2001 conference call, several persons speak in favor of HTTP-based URI.

  1. HTTP-based URI allows us to put something like RDDL document to the end point, which seems to be a general trend.
  2. If we'll take RELAX NG to ISO, then having an URI with "oasis" in it may be a little bit strange.

Also, "core" is proposed along with "main" and "structure".

Actual Resolution

http://relaxng.org/ns/structure/0.9 is choosen.

26. regularityConstraint: Restrict patterns to the regular language

Originator: mura034@attglobal.net Status: resolved

Description

TREX allows the following pattern.

<oneOrMore>
  <element> ... </element>
  <attribute> ... </attribute>
</oneOrMore>

In the computer science terminology, this is beyond the power of the "regular language". And therefore problematic for applications.

Shall we avoid this excessive expressiveness? If so, how?

The original post

Proposed Resolution

In the above post, M-san suggests to restrict <oneOrMore> and <zeroOrMore> to either

  • not contain <attribute> pattern directly/indirectly, or
  • patterns made of <attribute> and <choice> only.

jjc proposes the following restriction: "If a <oneOrMore> element has an <attribute> descendant, it must not have a <group> or <interleave> descendant."

KK suggests the following restriction: "If <group> or <interleave> is used under <oneOrMore>, then it cannot contain any <attribute>."

Actual Resolution

The TC decided to adopt the restriction by KK.

27. useOfQName: Use of QNames

Originator: Eric van der Vlist (vdv@dyomedea.com) Status: resolved

Description

RELAX NG uses QName to

  1. designate datatypes,
  2. refer to element/attribute names, and
  3. accommodate QName datatype of W3C Schema Part2

But for some, use of QNames in this way is something they want to avoid.

Can we avoid using QNames? If so, shall we avoid using QNames? If so, how?

The original post

Proposed Resolution

Eric proposed to declare the prefix-URI mappings in another independent way, as follows:

<namespace prefix="e" uri="http://www.w3.org/2001/XMLSchema-datatype"/>
<data type="e:integer"/>

Here is the original post.

The editor believes Eric also had an alternative proposal, which write URIs every time, like this:

<data namespace="http://www.w3.org/2001/XMLSchema-datatype" type="integer"/>

jjc suggests to introduce a new attribute "datatypeNamespace", which propagates like the "ns" attribute. This proposal will address the problem of using QNames for datatypes.

Murata-san opposes the use of QNames and proposes the following alternative solutions.

Another proposal made by jjc utilizes <div> elements to declare namespaces.

Several more proposals were also made. See the thread starting from here for details.

Circumstance

Some people (including the present editor, for the full disclosure) don't like to use QName in values for some reasons, including:

  1. It interferes with canonicalization of XML.
  2. It makes it impossible to change the prefix without any knowledge about the contents.

On the other hand, QName is easier to write for humans, and less verbose. And some people think the use of QNames is unavoidable.

Also, TC seems to have a consensus that RELAX NG grammar should be able to be written without using XML Namespace, if the author prefers so (because for many people XML namespace is still a new technology.)

Actual Resolution

In 2001/06/07, TC has voted to retain the current status; that is, use @ns to specify the default namespace and allow element/attribute names to have QNames.

28. listPattern: Introduce <list> pattern to replace <oneOrMoreToken>/<zeroOrMoreToken>

Originator: kohsuke.kawaguchi@eng.sun.com Status: resolved

Description

<oneOrMoreToken> and <zeroOrMoreToken> are adopted to make lists of strings possible. But it is discovered that a new pattern, namely <list>, can clone the semantics of <***OrMoreToken> patterns and simplify both implementations and the spec.

The original post

Proposed Resolution

The above original post contains the semantics of <list> pattern.

Circumstance

<***OrMoreToken> patterns do not allow us to have something like "a list of 4 integers", which is possible under W3C XML Schema. This proposal makes the list capability of RELAX NG more expressive than W3C XML Schema.

Actual Resolution

On 5/31/2001, TC has decided to adopt this proposal and removes <oneOrMoreToken> and <zeroOrMoreToken>.

29. symbolSpaceScope: Scope of key/keyref symbol spaces

Originator: jjc@jclark.com Status: resolved

Description

Currently, the symbol spaces of key/keyref are global. So two independently-authored grammars may accidentaly use the same key name. Is there any solution to this?

The original post

Circumstance

Sometimes, an author wants to refer to keys that another author wrote. That makes restriction difficult.

TC is now waiting for the public comments.

Proposed Resolution

  1. Allow <include> to rename keys.
  2. Allow <include> to have a flag to ignore(localize) keys in the included pattern.
  3. Have some kind of explicit scoping for each key. (How?)

Actual Resolution

TC has decided to adopt the proposal from James Clark, which extends symbol space name to QName.

30. redefinitionWithoutOriginal: Redefinition without original

Originator: kohsuke.kawaguchi@eng.sun.com Status: resolved

Description

Should it be OK to have a redefinition (<define> inside <include>) when that redefined pattern is not defined in the included file?

Consider the following example:

A.rng
<grammar>
  <include href="B.rng"/>
  <include href="C.rng">
    <define name="foo"> ... </define>
  </include>

B.rng
<grammar>
  <define name="foo"> ... </define>
</grammar>

C.rng:
<grammar/>

Circumstance

(Quoting from jjc's post) "If the user has done this, then they have probably made a mistake. On the other hand the semantics are clear. We can either make this an error or suggest that implementations give a warning."

Actual Resolution

TC has decided that such a redefinition has to be rejected. And an algorithm to detect this situation is available at the thread strating from here.

31. multiDefInAFile: Multiple definitions in the same file

Originator: kohsuke.kawaguchi@eng.sun.com Status: resolved

Description

TREX prohibits multiple definitions of the same pattern in the same file. That is, you can't write it like this:
<grammar>
  <define name="foo"> ... </define>
  <define name="foo" combine="choice"> ... </define>
</grammar>

Shall RELAX NG keep the same restriction, or not?

Circumstance

Quoting from jjc's post: " I found myself confused by this when reading RELAX grammars. I would find a reference to a label foo, then look for an elementRule foo; when I found it, I would assume it's the only definition. My assumption would be incorrect, and I would therefore misunderstand the schema (though eventually of course I would notice the other definitions and understand correctly). The other side of the argument is that this is an extra complication, and makes things slightly harder to explain. "

Actual Resolution

TC has decided to allow this (in 2001/6/7 conference call)

32. datatypeContext: Context information for datatype libraries

Originator: jjc@jclark.com Status: open

Description

Should RELAX NG specify the context available to the datatype provider for <value> and <param>? If so, what should be included (in-scope namespaces, entity declarations, notations declarations)?

33. attInList: <element> and <attribute> in <list>

Originator: mura034@attglobal.net Status: resolved

Description

It looks problematic to allow <element>s/<attribute>s within a <list> (may be it's not). We may want to restrict patterns that are allowed inside <list>.

This issue should be considered along with the issue #19 and #21.

Proposed Resolution

KK suggested to prohibit attributes inside list.

TC seems to have a consensus that these should be prohibited.

Circumstance

It is discovered that it is possible to modify the implementation to correctly process elements/attributes inside a list.

Actual Resolution

Due to the confusion arose by allowing elements/attributes inside a list, TC has voted to prohibit both elements and attributes inside list, in the conference call of 2001/06/14.

34. listDelimiter: allow non-whiteSpace delimiter for <list>

Originator: kohsuke.kawaguchi@eng.sun.com Status: resolved

Description

The original post

Actual Resolution

TC has decided not to incorporate this feature for Ver.1.0.

35. renameNameAtt: renaming the "name" attribute.

Originator: mura034@attglobal.net Status: resolved

Description

The original post

Actual Resolution

TC has voted to close this issue with no-action-required (2001/06/14).

36. multipleOperandsForNot: Allowing multiple operands for <not>

Originator: Jeni Tennison <mail@jenitennison.com> Status: resolved

Description

Currently, <not> pattern can only have one operand, and <not>p</not> is considered as the syntax sugar of <difference><anyName/>p</difference>. Ms.Tennison suggests that we can change <not> to have multiple operands by modifying its definition as:

<not>p1 p2 ...</not>

as equivalent of

<difference>
  <anyName/>
  <choice>
    p1 p2 ...
  </choice>
</difference>

This change is relatively easy because <not> is just a syntax sugar and it doesn't affect any other part of the spec. And as Ms.Tennison said, this "would be more convenient".

Actual Resolution

TC has decided to close this issue with no-action-required (2001/06/21). The reason was that <not> is inherently an unary operator, and semantics might become obscure if we allow multiple operands.

TC will revisit this issue when someone suggests to change the name of <not>.

37. defaultNsForValue: Resolution of the default namespace for XSD's QName datatype

Originator: Jeni Tennison <mail@jenitennison.com> Status: resolved

Description

Currently, our (conceptual) interface to datatype libraries is defined in such a way that the following pattern matches the following instance.

pattern:
<?xml version="1.0"?>
<element name="root"
         xmlns="http://relaxng.org/ns/structure/0.9"
         ns="http://www.example.org"
         datatypeLibrary="http://www.w3.org/2001/XMLSchema-datatypes">
  <!-- note that the value is unqualified -->
  <value type="QName">foo</value>
</element>

instance:
<root xmlns="http://www.example.org"
      xmlns:rng="http://relaxng.org/ns/structure/0.9">
  rng:foo
</root>

Because the unqualified QName value is considered to have the namespace URI of the defefault namespace. In this case, that is the namespace URI of RELAX NG, and this behavior is probably not what people want.

Proposed Resolution

If we modify the spec to resolve unqualified prefix to the value of "ns" attribute, instead of the default namespace URI of the pattern file, then the above pattern would match the following instance:

instance:
<root xmlns="http://www.example.org"
      xmlns:rng="http://relaxng.org/ns/structure/0.9">
  foo
</root>

The other resolution would be simply to close this issue without no action required.

Actual Resolution

In 2001/06/21, TC decided that the default namespace should come from the ns attribute, rather than the xmlns default namespace.

38. listInList: Allowing <list> in <list>

Originator: kohsuke.kawaguchi@eng.sun.com Status: resolved

Description

Allowing <list> doesn't buy anything. Should we prohibit that?

Actual Resolution

In 2001/06/21 conference call, we decided to prohibit them as an compile-time error.

39. reorganizeNC: simpler syntax for name class

Originator: mura034@attglobal.net Status: resolved

Description

Here is the original post.

Although there are several algorithms for manipulating name classes, the name class, especially <difference>, make it look compilicated. And even if it only look complicated, it still discourage implementors.

However, it is possible to change the primitives to make it look simple, while still preserving the same expressiveness.

Proposed Resolution

Here is the proposed new syntax.

name-class ::=
   name-class-literal
 | <t:anyName/>
 | <t:anyNsName ns="namespaceURI"/>
 | <t:anyNsNameExcept> name-class-literal+ </t:anyNsNameExcept>
 | <t:anyNameExcept>
     (name-class-literal | <t:anyNsName ns="namespaceURI"/>)+
   </t:anyNameExcept>
 | <t:choice> name-class name-class </t:choice> 

name-class-literal ::=
   <t:name ns="namespaceURI"> NCName </t:name>  

Several observations:

  1. Anything that can be written in the current syntax can also be written in this new syntax.
  2. <anyNameExcept> has the same semantics as the current <not>.
  3. It becomes trivial to check whether the given name class represents finite set of (URI,local) pair. We can even have a RELAX NG grammar that matches only to finite/infinite name classes.

Actual Resolution

In 2001/06/28 conference call, TC has voted to adopt James' proposal.

40. restrictInterleave: restriction of <interleave>

Originator: mura034@attglobal.net Status: open

Description

Here is the original post.

Generally speaking, <interleave> is hard to implement. It CAN be implemented, but it is difficult. Specifically, <interleave> makes it difficult to (1) perform validation by statically-compiled automaton, (2) perform subtyping algorithms, and etc.

So some degree of restrictions are desirable (at least for several people). If so, what restriction shall we employ?

Proposed Resolution

The original-post contains a proposal. But it still doesn't enjoy the consensus of TC.

41. patternFacetToText: adding the pattern facet to <text/> and <mixed/>

Originator: mura034@attglobal.net Status: resolved

Description

Here is the original post.

Circumstance

If we adopt the pattern facet to <text/> and <mixed/>, then we will be relying on W3C XML Schema Part 2.

James suggested that the pattern facet is not the right thing for this purpose.

TC is looking for real world use cases for this feature.

Actual Resolution

On 7/12/2001, TC has decided to close this issue without no action. A general agreement there was that we want to have something like this in the future version.

42. exceptPattern: <except/> pattern

Originator: jjc@jclark.com Status: resolved

Description

To solve the problem raised by Jeni Tennison, and the problem raised by MURATA Makoto. TC has decided to consider the <except> pattern proposed by James Clark.

Specifically, what do we allow as the descendants of a <except> pattern?

Actual Resolution

On 7/12/2001, TC has decided to resolve this as described in the current spec. Specifically, only <choice>,<data>, and <value> are allowed.

43. keyElement: adding <key>/<keyref> element instead of @key/@keyref

Originator: franck.delahaye@akazi.com Status: resolved

Description

A public comment from Franck Delahaye suggests that the current syntax of specifying key/keyref by attributes becomes clumsy sometimes. See his post for the actual example.

Proposed Resolution

James suggested to introduce dedicated elements <key> and <keyref> for this purpose.

Circumstance

On the conference call of 7/12/2001, there was a general agreement to move to the element syntax as suggested by James. But some people still wanted to have some time to think about what should be allowed inside key/keyref.

Actual Resolution

On 7/19/2001, TC decided to move to the element-based syntax.

44. dropStartName: drop @name from <start>

Originator: jjc@jclark.com Status: resolved

Description

The combine attribute and the name attribute of the <start> pattern have a complex interaction. We need to take some action to resolve this.

See the original post.

Circumstance

The name attribute on the <start> pattern is just a syntax sugar. So removing it will not affect the expressiveness of RELAX NG.

Proposed Resolution

Rather than getting down to the nitty-gritty of this interaction, James initially suggested that dropping the name attribute might be better.

His another proposal is to transform

<start name="N" atts> P </start>

into

<start>
  <ref name="N"/>
</start>
<define name="N" atts> P </start>

Actual Resolution

On 7/12/2001, TC decided to drop the name attribute from the start pattern. One of the reasons is that the interaction may be confusing for users even if we decided to transform it in unambiguous way.

45. oneOrMoreAndContents: Further restriction for the <oneOrMore> pattern

Originator: mura034@attglobal.net Status: open

Description

Murata-san argues that the use of <oneOrMore> should be further restricted and logically splitted into two different patterns, one for the repetition of attributes and the other for the repetition of elements.

See the original post.

Proposed Resolution

He proposed that "the content of <oneOrMore> is either (1) attribute-free, or (2) <attribute> or <choice><attribute>...<attribute>.

This makes the whole restriction simpler.

Circumstance

The current restriction is already restrictive enough to make RELAX NG a "regular language" (in the sense of computer science).

46. fragmentIdentifier: fragment identifier for href attribute

Originator: jjc@jclark.com Status: resolved

Description

What shall the spec do wrt fragment identifiers as the value of the href attribute? Should the spec allow, prohibit, or say nothig about this?

See the original post.

Actual Resolution

On 7/12/2001, TC closed this issue with no action. The author believes (but not sure) that the concensus there was to say nothing about this in the spec and have relevant RFCs stand by themselves.

47. URIprocessing: processing of @datatypeLibrary and @ns

Originator: jjc@jclark.com Status: open

Description

See the original post.

Proposed Resolution

On 2001/07/19 conf call, TC decided to:

  • Processors doesn't touch the value of the ns attribute. They should treat them as strings and compare them accordingly.
  • Processors hopefully validate the datatypeLibrary attribute by enforcing bunch of related RFCs, including a check of whether it is an absolute URI and without a fragment identifier, but it's not mandatory.

But James found that it is actually easy to enforce abovementioned checks for the datatypeLibrary attribute.

48. emptyContentModel: <eleemnt name="..."/> and <attribute name="..."/>

Originator: jjc@jclark.com Status: resolved

Description

The current RELAX NG allows empty attribute declarations (attribute pattern without a content model), which match attributes with any value. On the other hand, empty element declarations are prohibited.

Is the status quo fine? Or do we want to have symmetry? If so, how do we achieve it? By allowing empty element declarations? Or by prohibiting empty attribute declarations?

See the original post.

Actual Resolution

On 7/12/2001, TC decided to close this issue without any action. There was nobody who cares about this assymetry, and many people were happy with the current status.

49. nsNameAndPrefix: nsName using prefix

Originator: jjc@jclark.com Status: resolved

Description

Quoting from the original post:

If you are writing a schema using multiple namespaces, you can declare a
prefix for each namespace once using a normal namespace declaration and then
use QNames to refer to names from each of the namespaces.  However, there is
currently no comparable facility with ; there is no way to say
match any name whose namespace is the the namespace bound to prefix "x".
Should we add a way to do this?"

See the original post.

Actual Resolution

On 7/12/2001, TC decided to close this issue with no action. Many people didn't care about this functionality, and nobody came up with a good attribute name that can be used for this functionality.

50. optionalAttribute: Syntax sugar for optional attributes

Originator: mura034@attglobal.net Status: resolved

Description

Murata-san said he wants to have a syntax sugar for optional attributes, which are frequently seen in many schemata. Currently, we have to write

<optional>
  <attribute name="...">
    ...
  </attribute>
</optional>

See the original post.

Proposed Resolution

Murata-san suggested to have <optionalAttribute name="foo"> pattern as a syntax sugar for optional attributes.

JJC proposes <attribute name="foo" use="optional"> as a syntax sugar for optional attributes.

Actual Resolution

On 7/12/2001, TC closed this issue with no action. Many people didn't feel the necessity of this syntax sugar.

51. implicitGroupForStart: implicit grouping in <start>

Originator: jjc@jclark.com Status: resolved

Description

Quoting from the original post:

Currently

<start>
  <ref name="foo"/>
  <ref name="bar"/>
</start>

means

<start>
  <group>
    <ref name="foo"/>
    <ref name="bar"/>
  </group>
</start>

Would it be better for this to be an error or for it to mean

<start>
  <choice>
    <ref name="foo"/>
    <ref name="bar"/>
  </choice>
</start>

?

See the original post.

Actual Resolution

On 7/12/2001, TC decided to prohibit the <start> pattern to have multiple children (on the surface syntax). Only one child pattern is allowed for the <start> pattern.

52. overridingAtt: overriding attribute

Originator: jjc@jclark.com Status: resolved

Description

See the original post.

Circumstance

Although it is true that we don't have the described capability, it is also true that there are many other functionalities that RELAX NG doesn't have.

Actual Resolution

On 7/12/2001, TC closed this issue without any action primarily because no one wanted to have this functionalitiy.

53. emptyKey: empty strings as keys and keyrefs

Originator: jjc@jclark.com Status: resolved

Description

James found a loophole in our unambiguity constraint algorithm, and we need to fix that hole.

See the original post.

Actual Resolution

On 2001/07/19, TC decided to add an additional rule so that empty strings as keys will not cause a problem. Specifically, <key> ... </key> pattern will not match empty strings (which consists from whitespace characters) regardless of its body.

54. commonAnnotation: a spec for the common annotation

Originator: Michael Fitzgerald <mike@wyeast.net> Status: open

Description

It might be nice if there is a spec that defines a set of common annotations (e.g., documentation, default attribute values.)

What kind of annotation do we want to define, if at all.

Circumstance

See related discussions [1] [2].

55. externalRef: external grammar reference mechanism

Originator: mura034@attglobal.net Status: open

Description

Shall we change the language syntax so that it becomes easier to avoid rereading external grammars?

Circumstance

Currently, <externalRef> references to the start pattern of the referenced grammar and there is no mechanism to refer to named patterns in arbitrary grammars. Is there any way to solve it?

Proposed Resolution

James proposes <withGrammar> (or <grammarRef>), whose semantics is:

<withGrammar href="u"> p </withGrammar> = <grammar><include href="u"><start>p</start></include></grammar>

56. keyInList: key/keyref inside <list>

Originator: jjc@jclark.com Status: open

Description

Do we allow <key> and <keyref> inside <list>? Or not?

Circumstance

If we don't allow them inside <list>, then that means we cannot write patterns like:

<attribute name="refs">
  <list>
    <zeroOrMore>
      <keyref name="foo">
        <data type="token"/>
      </keyref>
    </zeroOrMore>
  </list>
</attribute>

which was known as 'IDREFS', and used by many well-known vocabularies, including XHTML and DocBook.

On the other hand, allowing them inside <list> has non-trivial impact on the unambiguity constraint. We have to prohibit patterns like:

<list>
  <zeroOrMore>
    <choice>
      <key name="foo">
        <data type="token"/>
      </key>
      <data type="decimal"/>
    </choice>
  </zeroOrMore>
</list>
	

issues.xsl



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


Powered by eList eXpress LLC