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.



added forgotten "QName" issue.
added "regularityConstraint" issue.


--
Kohsuke KAWAGUCHI                          +1 650 786 0721
Sun Microsystems                   kohsuke.kawaguchi@eng.sun.com
Title: RELAX NG Issues List

RELAX NG Issues List

Version $Id: issues.xml,v 1.12 2001-05-23 16:18:06-07 bear Exp bear $

Table of Contents

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 QName in attribute values

Introduction

RELAX NG issue list

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: open

Description

The original post

Proposed Resolution

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

3. xmlBase: xml:base support

Originator: jjc@jclark.com Status: postponed

Description

The original post

Proposed Resolution

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

4. wildcardPattern: add wildcard pattern

Originator: jjc@jclark.com Status: open

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.

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

Originator: jjc@jclark.com Status: open

Description

The original post

Proposed Resolution

jjc suggests form="prefixed|unprefixed".

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

Originator: jjc@jclark.com Status: open

Description

The original post

Cf.

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

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.

Actual Resolution

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

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: open

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.

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: open

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.

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

Originator: mura034@attglobal.net Status: open

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 prohibit them explicitly.

Some argues that such constraints are unnecessary.

20. orderSignificance: redefinitions and order-significance

Originator: jjc@jclark.com Status: open

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".

Circumstance

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

21. duplicateAttributes: prohibiting duplicate attributes

Originator: jjc@jclark.com Status: open

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

Some people want to ban this, but no algorithm is proposed yet.

22. datatypeOverlap: Overlapping with XML Schema Part 2

Originator: mura034@attglobal.net Status: open

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.

23. nestedGrammar: Prohibiting nested grammars

Originator: mura034@attglobal.net Status: open

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.

24. datatype: Datatype and Identity Constraint

Originator: ??? Status: open

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.

25. nsURI: Namespace URI of RELAX NG

Originator: jjc Status: open

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".

26. regularityConstraint: Restrict patterns to the regular language

Originator: mura034@attglobal.net Status: open

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.

27. useOfQName: Use of QName in attribute values

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

Description

TREX uses QName to designate datatypes. But for some, use of QNames in attribute/element values is something they want to avoid.

Shall we avoid using QNames in values? 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"/>

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.



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


Powered by eList eXpress LLC