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: Re: Comments on the specification



> - Should we move "7. Restrictions" before "6. Semantics"?

I thought about that.  I didn't do it, because that would make the first
inference rules that a reader encountered be those that are now in section
7.4.  I think that would be too hard.  I want to start the reader off with
some simple and easy inference rules; name classes are perfect for that.
Section 6 seems the right place to introduce the concept of a proof system,
which means it needs to precede section 7.

> 2. Data model
>
> The first itemized list says:
> "the sequence never contains two consecutive strings"

That's talking about a sequence that represents the children of an element.

> However, "m1, m2" as defined in 6.2.2 may create such
> two consecutive strings.

Sequences in general are not so restricted.  Note that 6.2.8 has
normalized(m) in the antecedent to ensure that you can't prove the validity
of something that isn't legal in the data model.

What's the best way to clarify this?

> 3. Full Syntax
>
> - If the value of the datatypeLibrary attribute is always absolute, we
> should explicitly say so.
>
> - Can values of the datatypeLibary attribute contain fragment
> identifiers?  I think that this should be disallowed.  We use URIs
> merely as identifers, but fragment identifiers are used for
> describing behaviours of user-agents.

These two points fall within the "datatypeLibrary and ns attribute
processing" issue.

> - Strictly speaking, we do not have to allow #xD, since line-feed
> characters are replaced by #xA.  However, we have to allow a character
> reference  , since the XML processor converts   to a space
> character.  Then, why not #xD?

It would be strange to disallow #xD.

> - Isn't the type attribute optional for <value>?

Yes.  There's a "?" following the attribute value that is intended to
indicate this. Is there some way I should fix the notation to make this
clearer?

> - "A boolean must be true, false, 1 or 0".  I don't like this choice
> of permissible values.  However, if we omit "global", we do not need
> booleans at all.

I hope we can get rid of "global", which would make this point moot.

> 4.1 Annotations
>
> We certainly do not remove xml:base.

I believe we do remove it. xml:base is used in determining the value of the
[base URI] property of an element info item, which is in turn used to
construct the base URI of the context of an element.  Once you have
constructed an instance of the data model, xml:base can be thrown away.

Maybe we need something emphasizing that these transformations are applied
at the data model level, and that the parsing and infoset construction takes
places before the transformation rules are applied. Maybe a note in 4.1 too?

> 4.4 externalRef element
>
> > "from prevoius sectoins to this section"
>
> I first thought thes means Sections 1 through 3.

What do you want this to say? It would be a bit painful in 4.6 to say "in
Section 4.1, Section 4.2, Section 4.3, Section 4.4 and Section 4.5".

> 4.6 Last para
>
> "other then" should read "other than".

Fixed.

> 4.7
>
> I would like to make sure which attributes in a grammar
> affects external grammars.
>
> Consider
>
> <grammar...>
> <div ns="..." xml:base="..." datatypeLibary="...">
>   <include href="bar.rng"/>
> </div>
> </grammar>
>
> .
>
> In my understanding, the ns and datatypeLibrary attribute
> applies to bar.rng, but xml:base does not.  I think that
> a note about this would be hellpful.

"ns" definitely does. xml:base definitely doesn't. As I've written the spec,
datatypeLibrary would apply to bar.rng, but that wan't intentional and I'm
not sure that's a good idea.

> 4.16
>
> The example is wrong.  We need combine="c".

It's supposed to be a general rule, not an example.  I can't put the combine
attribute in, because one of the definitions might not have a combine
attribute. In fact the prose is wrong, because it needs to say that the
combine attributes are removed at some point.  Suppose I make the text
before this:

"Thus, for any name, if there is more than one define element with that
name, then there is a unique value for the combine attribute for that name.
After determining this unique value, the combine attributes are removed. A
pair of definitions ... is combined into ..."

> 6.2
>
> I would like to replace "bag" with "set".

Yes, that makes sense given how we have dealt with duplicate attributes. (We
still need bags for keys of course.)

> 6.2.2
>
> To be precise, "+" for keys and key references have
> not been defined.

OK.  I'll fix that.

James




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


Powered by eList eXpress LLC