W3C home > Mailing lists > Public > public-sml@w3.org > December 2007

[Bug 4774] definitional schema documents should be preferentially used over all other sources when validating instances

From: <bugzilla@wiggum.w3.org>
Date: Wed, 05 Dec 2007 19:56:46 +0000
CC:
To: public-sml@w3.org
Message-Id: <E1J00MQ-00052a-Pe@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4774





------- Comment #11 from sandygao@ca.ibm.com  2007-12-05 19:56 -------
> Regarding #1, yes the extra spaces were intentional to align the schema
> contents.

I have to admit that the new indention doesn't look as nice as the old way. Why
does <identity> need to indent that far when it's parent <model> is at the
beginning of the line? Is it because of the "xmlns"? Child elements typically
don't align with attributes in the parent tag. (It would be nice if "xmlns" and
"xmlns:xs" were aligned.)

But this is not something worth having a war for ... :-) Leaving it up to the
editors.

> 2.  In section 4.4, for "schema-incomplete". "A required schema is 
> not included
> ..." Maybe it's more accurate to say "Some required schema documents*may* not
> be included ...".
> 
> This does not make sense to me. Either the documents are included or not, in
> which case 
> the IF document is schema-complete or not. I'm not sure what is intended by
> "may".

There are 2 ways to distinct the 2 cases.
1. Known to be complete vs. not known to be complete
2. Known to be complete vs. known to be incomplete

I always had #1 in mind when thinking about schemaComplete. And the drafted
wording takes #2.

I agree that #2 could be more useful in certain cases, especially for
consumers, so that they know exactly what to do. But from the producers'
perspective, is it always possible to make that distinction? What if it does
not have all the information to determine whether some schema documents are
missing?

By taking the first interpretation, producers have more flexibility: if they
know enough, they can set schemaComplete=true; otherwise it's safe to use
"false" (which is not the case for #2). And I don't think this hurts consumers.
When complete=true, they never go outside the IF to look for schema documents;
when complete=false, consumers can decide what to do.

> 3.  In the following paragraph "... distinguish between these two cases and
> that
> is not always ...". Suggest to change "and" to "because".
> 
> The sentence in the spec is "It is necessary for an SML-IF producer to
> declaratively 
> distinguish between these two cases *and* that is not always possible based on
> the content alone. "
> 
> I think "and" is correct. "It is necessary to distinguish..." is a true
> statement whether or not
> it is possible based on content alone - not 'because' it is not possible based
> on content alone.

Hum... I would say the reason it is "necessary" is because "it is not possible
to tell". If a comsumer can always tell, then why do we require producers to
distinguish?

> 15.  Maybe it's helpful to have a default value for "schemaComplete":
>     <xs:attribute name="schemaComplete" type="xs:boolean"/> becomes
>     <xs:attribute name="schemaComplete" type="xs:boolean" default="true"/>
> 
> This needs a group decision. We should be careful to assess the impact of not
> setting this correctly. In other words, which is the worst situation:
> - schemaComplete is 'true' and the IF document is really not schema complete?
> or
> - schemaComplete is 'false' and the IF document is actually schema compete?

Oops. Meant for the default to be "false".

Whether to have this default makes no real difference. The only place it
affects is probably when we talk about the value of this attribute. Without the
default, we need to say "if ... is present and its value is ..."; with the
default, we know the attribute will always be there, then we can simply say "if
...'s value is ...".
Received on Wednesday, 5 December 2007 19:56:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:56:08 UTC