QNames in the extended code values Re: Notes about the three TAG TC documents

[Stephen Green <stephen.green@documentengineeringservices.com>]

Good news: I did eventually find what had troubled me about
QNames in attribute values and it turned out I had misunderstood
it completely. Looks like there is not problem. The XSLT would
properly handle the QName attribute value as long as it can 'see'
a namespace declared in scope for the prefix. There should be
no problem. I withdraw my issue/comment. Apologies for mistake.

Best regards

Steve
---
Stephen D Green




2010/1/5 Stephen Green <stephen.green@documentengineeringservices.com>:
> In advance of the TAG TC meeting later today I have made
> some notes about the three documents - guidelines, model
> and markup so I thought it might be helpful to send these
> out beforehand, then to go through these points on the call.
>
> 1) Test Assertions Guidelines
>
> a) these are fairly stable and mature
>
> b) there is no need for a conformance clause (other than
>    basic statement that the document is not normative)
>
> c) Table added on p28 - this has a minor problem where
>    there is the second part of 'Test Assertion Document'
>    carried over to the second page which is confusing
>
>
> 2) Test Assertions Part 1 - Test Assertions Model
>
> a) not every single attribute in the model has a definition
>    in the model specification - semantics covered only in
>    in the general description of the class for some attributes
>    - is this OK?
>
> b) as minuted, would we be able to ask for some editorial
>    technical writer review from Dmitry in Sun?
>
> c) could we remove the word 'class' from the formal
>    definitions so that in general
>    'class : xyz (...'   becomes just 'xyz (...'    ?
>
> d) is the conformance clause OK?
>
> 3) Test Assertions Part 2 - Test Assertions Markup
>
> a) see 2 a) and 2 b) above - same applies here
>
> b) is the namespace OK? I reverted recently to
>    '.../090930' to help an early adoption which uses this
>    namespace and was not affected by any of the
>    later changes to the schema. Bear in mind this is
>    all still in draft mode and namespace versioning
>    rules do not need to apply as yet.
>    We need a namespace strategy for processing the
>    markup spec and schema. I'd prefer if we kept what
>    we have if appropriate, unless public review leads
>    to breaking changes requiring a new namespace. If
>    we do need to change it further how would it change?
>
> c) I've a feeling we may still have an issue with the use
>    of QNames in content for enumerating the prescription
>    level codes. Dennis and I agreed a technique using the
>    schema to constrain enumeration extensions as only
>    allowing QNames with a prefix. However I have worries
>    this may cause problems with anyone using XSLT on
>    instances including such extensions.
>
> d) is the conformance clause OK?
>
>
> Best regards
>
> Steve
> ---
> Stephen D Green
>