[dsdl-discuss] Re: Part 4

Martin,

Thanks for your suggestion. Here is my reply.

> Introduction
> The following paragraphs, taken from Part 1, could usefully be added at the
> start of the Introduction to better set the scene:

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

> In the first of the current paragraphs, change "easily combine different" to
> "allow the interworking of"

Agreed.

> Add to the end of the second sentence in the second para "and provides
> examples of its application"

Agreed.

> NB. If comments relating to Clauses 6 and 8 given below are adopted then
> references to these clauses will need to be removed and the numbering of
> remaining clause references adjusted accordingly.

Agreed.

> In the third paragraph change "Influenced" to "The draft was further
> influenced" and delete "and the committee draft". Change "the final" to "a
> revised"

Agreed.
>
> 1 Scope
> Add "a" after "specifies".
> Change "and attributes" to "or attributes"
> Change "the schema languages" to "any schema languages, including those" [We
> should not exclude the use of other schema languages with namespace control
> of sets, including W3C Schemas.]

Agreed.
 
> 2 Normative References
> What you have as an unnumbered note here is treated as normative text in
> other parts. We need to decide on a common approach to this statement. As
> the comment affects the interpretation of normative text I believe it should
> be a normative paragraph rather than an informative note. [If it is retained
> as a note it needs to be numbered in the same sequence as other notes!]

I copied this note from Part 2. But I agree to changes this to a normative
paragraph.

> 3 Terms and Definitions
> The same term should not be defined more than once within the standard.
> Terms copied from Part 2 should be removed and a reference to the
> definitions in Part 2 should be made. (If any terms are taken from Part 3
> they should be replaced by a cross-reference to this part.)

I read C.1.4 of ISO/IEC Direcitives Part 2 (Fourth edition, 2001). Although it
allows another possibility (which is to put an informative reference after the
duplicated text), I think your suggestion is better.

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

> 3.14
> Change "the schema" to "a schema"

Copied from Part 2.

> 3.15
> After "specification of" insert "the model of"

Copied from Part 2.

> 3.17
> Change "determine" to "determines"

Copied from Part 2.

> 3.18
> Change "create" to "creates" and "invoke" to "invokes"

Agreed.

> 3.26
> Change definition to read "an element for which a single namespace URI
> applies to itself and all descendants"

Thanks. Agreed.

> The term mediaType used in the normative text needs defining in Clause 3

Thanks. We should borrow some text from RFC 2045 or RFC 2046.

> 5.1
> Remove first sentence and reorder sentences of first four paragraphs as
> follows:
>
> "XML documents representing schemas and instances shall be well-formed in
> conformance with W3C XML and shall conform to the constraints of W3C
> XML-Names. An XML document is represented by an element.
>
> This abstract NVDL data model is an extension of the data model of RELAX-NG.
> Names, contexts, attributes, and strings in the NVDL data model are
> identical to those in the RELAX NG data model. Elements in the NVDL data
> model are extended as describe in this clause.
>
> An NVDL emenet consists of:"

Thanks for this suggestion. Agreed.

> In the paragraph following NOTE 1, change "(say ASN)" to "(ASN)" and "when
> ASN" to "when the ASN". In the following paragraph change "(say ESN)" to
> "(ESN)" and "when ESN" to "when the ESN".

Agreed.

>Also change the preceding "for an
> element" to "for one or more elements in a given namespace"

Actually, an element slot node is always created a place holder for a single element.
However, when element sections are attached to elements, an element slot node
may be replaced with a sequence of one or more element sections.

> EXAMPLE 1
> Change "First, every" to "Every". Change "an XML declaration, comment and
> processing instruction" to "the XML declaration and any comments or
> processing instructions"

Agreed.

> EXAMPLE 2 (and all examples based on this)
> Do not use empty strings for attribute values. All attributes must be given
> specific values, even if they are the same as the attribute names, or just
> numbers. (Empty strings in double quotes are difficult to read.)

Agreed.

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

> 5.3
> Change "XML document" to "XML instance"
> Change "This process is done as follows." to "Decomposition is achieved
> using the following rules:"

Agreed.

> 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"? In my understanding of G.4 of Directives Part 2 (fourth edition),
"can" is a synonym for "be able to" or "there is a possiblity of".

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

> In para preceding EXAMPLE 1, change "ES is represented by E" to "ES contains
> those children of E that belong to N" and delete the last sentence.

No, because ES contains E.

> In EXAMPLE 2, explain why attributes with no namespace need to be assigned a
> separate ASN, and change 'two attributes of the namespace "".' to "two
> attributes that have not been assigned a namespace prefix."

Since we follow the RNG data model, attributes without prefixes are assumed
to have names comprising "" and local names (see the last para of page 7
of DSDL Part 2).

> Change, twice, "It has no element slot nodes." to "It has no element or
> attribute slot nodes."

Agreed.

> 5.4
> At end of first sentence add "with the same namespace URI".

Actually, {foo:a=''} can be attached to <bar:a $asn></>, even when foo and bar
reference to different namespaces.

>Change "then ASN
> is" to "the the ASN can be"

"can" means a possibility. How about "shall"?

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

> 5.5 (and elsewhere)
> Use suffixes for things like E1, E2 and Em, and use n in place of m (in some
> clauses m and n are mixed indiscriminately)

Agreed.

> The sentence preceding EXAMPLE 1 does not make sense, mainly becaus it does
> not identify any requirement for attached elements to have matching
> namespace URIs. The example shows two different URIs, which would seem to
> defeat the purpose of namespace-based dispatching!

No, this example is perferctly correct. A validation candidate needs not to
belong to a single namespace. Neither NRL nor MNS have such a restriction.

> In EXAMPLE 2 change "5.3" to "5.2". You need to explain why there is no
> reference to $esn2 but one to $esn1.

We should reference Example 2 of 5.3. $esn2 is replaced with the fourth
and fifth element sections.

> 5.6
> Change "be casted" to "be cast" and delete "This is done as follows."

Agreed.

> 5.7
> Change, twice in the first paragraph and once in the note, "RELAX NG data
> model" to "NVDL data model". [5.1 makes it clear that NVDL extends the RELAX
> NG data model.]

There are two possibilities. One is not to mention the RELAX NG data model
in 5.6 (i.e., we delete the first sentence of 5.6) and accept your proposal
and further state that slot nodes are never passed to validators. The other
is the current wording. Although I see nothing wrong in the current wording,
I think a note about the relationship between the RNG data model and NVDL data
model will be very helpful.

> 6
> Remove the RNG model to a normative Annex (which must procede informative
> ones). Either replace this with a diagram of the model, or combine clauses
> 6, 7 and 8 under the heading of Full and Simplified Syntaxes and make
> existing text of Clauses 6 and 8 the first and last paras of the new clause
> (after suitable modification)

I agree to combine clauses 6, 7, and 8 and move RNG schemas to normative appendixes.

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

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

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

> Is the last part of the last sentence actually true? ("an element" implies a
> single object with no substructure)

No, in XML, "an element" may have subelements. This has been so clear in XML 1.0
as well as in DSDL part 2. By the way, this sentence is copied from DSDL Part 2.

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

> 7.9
> 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.
(In my reading of Annex G of Direcitves Part 2, "must" means
requirements of external statutory obligations and "shall" means
requirements of the standard in question.)

> 7.12
> Change "in mode" to "with mode".

How about "mode elements are transformed so that they
do not have child mode elements."

>Change Im and km to just in all cases (do
> not mix km and lm, and do not use the ISO approved abbreviation for
> kilometer, km, in this context)

Agreed.

-- 
MURATA Makoto <murata@hokkaido.email.ne.jp>
--
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)