- From: <bugzilla@wiggum.w3.org>
- Date: Wed, 05 Dec 2007 19:56:46 +0000
- To: public-sml@w3.org
- CC:
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