[dsdl-discuss] Re: Part 4

Murata-san

> I am happy with this. By the way, are we going to start a CD ballot for
Part 1 in
> June?

Would you like it to be formally submitted to National Bodies at this stage?
(I was thinking of it as a working draft until such time as we had agreed on
what each of the parts was to do, but am happy to put it out for ballot if
you think this would be advantageous at this stage.)

> By the way, some of the definitions are borrowed from Part 2 and then
slightly
> modified. For example, "full syntax" and "simple syntax" in Part 2 and
those
> in Part 4 are completely different. The former is for RNG schemas but
> the latter is for NVDL scripts. In such cases, I will not reference to
Part 2.

If there is a clearly different definition then a new definition should be
defined in this Part to locally override imported definitions.

> > 3.6 instance
> > The definition of instance should not be tied explicitly to RELAX NG: it
> > should be validatable against any schema.

> I am puzzled, since the current definition does not reference to RNG.

My mistake: please ignore.

> > NB. To avoid confusion I would like to see all examples in the document
> > numbered consecutively so that no two examples have the same number (the
> > Directives allow this as an alternative numbering technique)
>
> Which part of the directives? 6.5.1 of ISO/IEC Direcitives Part 2
(Fourth edition, 2001)
> says:
>
> A single example in a clause or subclause shall be preceded by “EXAMPLE”
,
> placed at the beginning of the first line of the text of the example.
> When several examples occur within the same clause or subclause, they
> shall be designated “EXAMPLE 1”, “EXAMPLE 2”,“EXAMPLE 3”, etc.

I see this is the same in the latest directives. The copy I used, which was
3rd edition, also allowed consecutive numbering throughout a document for
electronic publications, but the new directives seem to have dropped this
[it's what we used in 13250, and makes things a lot easier to refer to,
especially in this type of document where Example 3 in Clause X.Y.Z refers
back to Example 2 in Clause X.Y.Y which in turn refers to Example 1 in
X.X.X. All very confusing, and much easier if you can refer to uniquely
numbered examples :-( ]

> > Change "Then, the attribute set of E is" to "The attribute set of E can
then
> > be"
>
> How about "The attribute set of E shall be modified" or "The attribute set
of
> E is then modified"?
I prefer the second of these, but this is does not allow for the following:
>
> > NB: This rule is unnecessarily strict as it means that an AS has to be
> > created for a namespace even if there are no attributes with that
namespace.
> > The rule also fails to make it clear that whether only those namespaces
> > actually identified within the element are used for N, or whether all
> > namespaces currently in scope must be applied.]
>
> I will try to reformulate my wording. My intention is as follows:
> - No, if the are no attributes with that namespace, AS is not created.
> - Only those namesapces actually identitied within that telement are used.
> >Change "then ASN
> > is" to "the the ASN can be"
>
> "can" means a possibility. How about "shall"?

OK, providing every case requires it (e.g. when there is nothing in the set)

> > The EXAMPLE in this clause seems to be incorrect. There are two
different
> > namespaces declared, which I believe is invalid.
>
> Why is this invalid? I see nothing wrong in this example.
>
> > Rather than replacing $asn3
> > by its values $asn4 should have been should have been replaced by its
values
> > as they share the containing element's namespace.
>
> I am puzzled. Why?

Then I am puzzled because the examples don't make sense to me. You need to
explain them more. If I cannot make sense of them as a member of the
committee then new readers have no chance. (I'll re-evaluate them during
ballot to see if it makes any more sense the next time through.)

> > The pattern for MediaType is not adequate to correctly distinguish
mediaType
> > definitions
>
> I created the pattern from RFC 2045. What is wrong about this pattern?

As you had no reference to RFC 2045 then it was unclear that the pattern was
to be judged against those rules.
>
> > Is the pattern for path adequate for correctly identifying paths?
>
> I believe so. The schema in NRL has one mistake, but I corrected it.
> Is something wrong with the pattern for paths?

I need to check in detail on the next review. My initial reaction is that in
itself it is not adequate, but I haven't tried it out against examples yet.

> > 7.1
> > Change "given in the previous clause" to "can be"
>
> How about "shall be"? Probably, I do not understand English, but English
> for ISO standards is a variation of English.

The difference between "shall be" and "can be" is that in the first case it
"always must be" and in the secont it means "may in appropriate cases be".
I'm not convinced that we should be saying the replacement must occur in all
cases, but if you are then "shall be" is the correct term.
> > 7.8
> > Thie rule appear to force the root element's schemaType to override that
of
> > any child, removing any chance of inheritence. Is this intended? If so
add a
> > note explaining why it is required.
>
> I wrote: "this attribute is copied to each validate element not having
> either a schemaType attribute or schema element.", which appears to be
> misleading. How about "this attribute is copied to those validate
> elements which have neither a schemaType attribute nor a schema element."

much better
> > Change "value that is" to "value, which must be".
> >
> > 7.10
> > Change "value that is" to "value, which must be".
>
> Agreed, but I think "value, whch shall be" is better.

Agreed (with the typo corrected)
>
> > 7.12
> > Change "in mode" to "with mode".
>
> How about "mode elements are transformed so that they
> do not have child mode elements."
Much better

I look forward to trying to get to grips with the final version and to
sorting out how to use this properly. I'm going to have to draw myself some
diagrams before I can get my head around it. At present the RELAX spec is
not sufficient for me to visualize what is happening fully.

Martin

--
DSDL members discussion list
To unsubscribe, please send a message with the
command  "unsubscribe" to dsdl-discuss-request@dsdl.org
(mailto:dsdl-discuss-request@dsdl.org?Subject=unsubscribe)