The latest issue list (4/25)

[Kohsuke KAWAGUCHI <kohsuke.kawaguchi@eng.sun.com>]

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

Title: TREX Issues List

TREX Issues List

Version $Id: issues.xml,v 1.4 2001-04-25 17:57:33-07 bear Exp bear $

Table of Contents

Issues

1. Should empty elements allow whitespace?

2. Name of "difference" element

3. xml:link 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

Introduction

TREX 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. xmlLink: xml:link 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.

7. grammarName: Name of "grammar" element

Originator: jjc@jclark.com Status: open

Description

The original post.

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

Description

The original post.

10. versioning: Versioning

Originator: jjc@jclark.com Status: open

Description

The original post.

Proposed Resolution

(a) Put a version in the TREX 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?)

11. MNrepeat: Repeat M-N times

Originator: jjc@jclark.com Status: open

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.

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.

13. diffPattern: Allow difference of patterns

Originator: jjc@jclark.com Status: open

Description

The original post.

14. IdIdref: ID/IDREF problem

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

Description

The original post. Summarization/generalization by jjc.

Interactions and Input

Proposed Resolution

no solid proposal is made yet.

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

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.

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, TREX 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 TREX 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

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

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

( original posts )

Circumstance

One of the touchstone will be XHTML modularization.

Proposed Resolution

Proposed restriction is 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."

21. duplicateAttributes: prohibiting duplicate attributes

Originator: jjc@jclark.com Status: open

Description

TREX 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?

( original posts )

Proposed Resolution

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