OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

tag message

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


Subject: Re: Starting an issues list?


I'd also like to make another minor correction where,
debatably, a discrepancy exists between schema and
XML Representation for sourceDocument (the last
element to receive a mod and so the most likely to have
such an error). I'd like to change

<sourceDocument
  revision ? = 'xsd:normalizedString'
  version ? = 'xsd:normalizedString'  {any attributes with non-schema
namespace . . .}>
Content: xsd:string
  {this element also allows mixed content so text can be included
directly as part of the main element's content}
</sourceDocument>

to

<sourceDocument
  revision ? = 'xsd:normalizedString'
  version ? = 'xsd:normalizedString'  {any attributes with non-schema
namespace . . .}>
  {this element also allows mixed content so text can be included
directly as part of the main element's content}
</sourceDocument>

by just removing "Content: xsd:string" as it is the
mixed content which allows the text to be added,
not an XSD 'base=xs:string' - as the schema has:

<xs:complexType name="sourceDocument_type" mixed="true">
		<xs:attribute name="revision" type="xs:normalizedString"/>
		<xs:attribute name="version" type="xs:normalizedString"/>
		<xs:anyAttribute namespace="##any" processContents="skip"/>	
</xs:complexType>
	
Best regards

Steve
---
Stephen D Green




On 4 February 2010 17:28, Stephen Green
<stephen.green@documentengineeringservices.com> wrote:
> All I will do with these non-substantive changes
> to the schema (separate and inline) is change
> those places where we have
>
>        <xs:complexType name="***Shared_type" mixed="true">
>                <xs:simpleContent>
>                        <xs:extension base="***_type">
>                                <xs:attribute name="conflict" type="***ConflictCode_type"/>
>                        </xs:extension>
>                </xs:simpleContent>
>        </xs:complexType>
>
>
> to
>
>        <xs:complexType name="***Shared_type">
>                <xs:simpleContent>
>                        <xs:extension base="***_type">
>                                <xs:attribute name="conflict" type="***ConflictCode_type"/>
>                        </xs:extension>
>                </xs:simpleContent>
>        </xs:complexType>
>
> (where '***' is 'predicate', 'target', 'var', etc)
>
> This change has little effect - it only improves the
> clarity of the schema and the fidelity to the spec
> representation. The 'mixed=true' is just ignored
> by schema processors/parsers. Just as well to
> remove it though I think.
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> On 4 February 2010 16:06, Stephen Green
> <stephen.green@documentengineeringservices.com> wrote:
>>> I passed it
>>> through the W3C online schema validator and found I got
>>> a few warnings because there are places where simpleContent
>>> is specified as having mixed content (mixed content when
>>> there are no child elements, I think that means).
>>
>> OK, I found the causes of these 'warnings' and could correct
>> them easily enough but that would warrant another draft of just
>> the markup spec and the schema. I think it's worth this very
>> minor change just to avoid misunderstanding of the important
>> schema, even though it does not affect instances.
>>
>> I'll send out new drafts of the schema and the spec in a few
>> hours time.
>>
>> Best regards
>>
>> Steve
>> ---
>> Stephen D Green
>>
>>
>>
>> On 4 February 2010 15:23, Stephen Green
>> <stephen.green@documentengineeringservices.com> wrote:
>>>
>>> Dear TAG TC,
>>> I guess we will need an issues list. Any progress/thoughts
>>> about having and using a Jira account?
>>> I'm not sure how our TC comments will need to be separated
>>> from external/public comments. I will have a few comments
>>> of my own on how things might be improved after public review.
>>> After this month I may have to submit comments via the
>>> public comments list. Are we supposed to keep TC comments
>>> separate and try to make such comments before the review
>>> rather than during it?
>>> My comment for now is that I think there would be special
>>> benefit in having the schema itself reviewed. I passed it
>>> through the W3C online schema validator and found I got
>>> a few warnings because there are places where simpleContent
>>> is specified as having mixed content (mixed content when
>>> there are no child elements, I think that means). Some
>>> review of this and any other related schema design features
>>> might be warranted and might require minor changes to the
>>> model as well as the schema (but these should not, I hope,
>>> affect XML instances).
>>> Best regards
>>>
>>> Steve
>>> ---
>>> Stephen D Green
>>>
>>
>


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