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: [tag] Re: Starting an issues list?


Dennis

These are really just the kinds of corrections that
OASIS requires before public review - just to ensure
quality of artefacts (in this case the schema). There
are no changes (apart from the well-considered
conformance clause change) that would need review.
It is proper to use a reference tool like the W3C
online reference schema validator to validate the
schema before public review. In this case it showed
no errors but a handful of warnings which following a
few corrections it no longer shows.

Also, I'll have to hand over my work at the end of
this month so I felt it all the more important to
ensure proper quality of the technical bits that might
be harder for someone else to pick up later after
the review. I'll be able to make comments (via comment
list) but not to edit the documents or make contributions
only appropriate for TC members.

Best regards

Steve
---
Stephen D Green




On 4 February 2010 19:48, Dennis E. Hamilton <dennis.hamilton@acm.org> wrote:
> I assume that you would not be surprised if I exhibited a certain petulance
> over the dismissal of my recent suggestions while all of these
> "non-substantive" changes are being proposed for slip-streaming into the CD
> for Public Review?
>
> Or do I misunderstand where these changes are being made?  It would be handy
> if our internal review and the public review base documents were not
> different, especially since we haven't even started Public Review yet.
>
>  - Dennis
>
> -----Original Message-----
> From: stephengreenubl@gmail.com [mailto:stephengreenubl@gmail.com] On Behalf
> Of Stephen Green
> Sent: Thursday, February 04, 2010 09:45
> To: TAG TC
> Subject: [tag] Re: Starting an issues list?
>
> Or I'm considering changing it to a better schema expression
>
>        <xs:complexType name="sourceDocument_type">
>                <xs:simpleContent>
>                        <xs:extension base="xs:normalizedString">
>                                <xs:attribute name="revision"
> type="xs:normalizedString"/>
>                                <xs:attribute name="version"
> type="xs:normalizedString"/>
>                                <xs:anyAttribute namespace="##any"
> processContents="skip"/>
>                        </xs:extension>
>                </xs:simpleContent>
>        </xs:complexType>
>
> to avoid the mixed content, in which case the spec will read
>
> <sourceDocument
>   revision ? = 'xsd:normalizedString'
>   version ? = 'xsd:normalizedString'
> {any attributes with non-schema namespace . . .}>
>  Content: xsd:string
> </sourceDocument>
>
> This seems better and improves the mapping to the model.
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>
>
>
>
> On 4 February 2010 17:36, Stephen Green
> <stephen.green@documentengineeringservices.com> wrote:
>> 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
>>>>>
>>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  Follow this link to all your TCs in OASIS at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>


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