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: May24 TAML PDF review - Update


 

Dennis:

 

Most comments make sense to me.

See inline <JD> for those that may need alternative solution to what you suggest.

 

Regards,

Jacques

 

 

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Thursday, May 26, 2011 8:44 PM
To: TAG TC List
Subject: [tag] RE: May24 TAML PDF review - Update

 

On p.6, last paragraph of section 2.1, I now wonder about the use of "declared" for elements.  I think elements are expressed.  I think this might do better:

 

"Elements 'testAssertion', 'testAssertionSet', and 'testAssertionDocumentHeader' are global elements and can be top-level elements in a TAML markup instance (e.g., be root elements of an XML document).  All other TAML elements are local in a markup instance under the TAML schema (i.e., are descendant children of a global element as provided by the schema).".

 

On page 7, new text about extensions near the top of the DIFF page.  There are a couple of things.

In the second section, I think "At the exception ..." should be "With the exception ... ."

 

The last sentence of the addition begins with "Note that ..." and then has a normative statement.   That sentence can be removed. 

 

With regard to the allowance of TAML markup in <taml:common>, ... <taml:comment>, and the restriction on child elements, I think a better wording is needed.  I will look at that separately.

 

<JD> will add new 4th level subsections, but keep intro text before RelaxNG.

 

On p.7 last sentence, "relative of their containing element" should be "relative to their containing element"

 

p.8 Example - there should be a non-normative reference to the NIEM specification.  Thanks for expanding the abbreviation.  Is there a specific specification that can be referenced in the non-normative section?

 

p.10 top of page, this is talking about the <derivedSourceItem> element but there is no accompanying Compact Relax NG definition as a lead-in.   There seems to be somethiing out of order here, in comparison to how all of the other notions have a preceding Compact Relax NG definition that is further explained with subsequent  prose.

 

<JD> We say: "The compact Relax NG definition of taml:derivedSourceItem is same as for  taml:refSourceItem", and we mentioned that. So no need for a separate RelaxNG def.

 

p.10 Starting with the Compact Relax NG definition for <taml:comment>, the descriptive text is now in front of the Relax NG rather than after it as in the preceding descriptions.  I suggest that the description be after the Compact Relax NG definition for the respective element.  (That is, the new paragraphs are good but should be after the Relax NG.)   I must have misled you with one of my previous coments.

 

p.14 2.3.10 second paragraph below the schema.  HTML cannot be used.  HTML markup is not well-formed XML, doesn't have namespaces, etc.  Try "can be a mixture of text and XML elements."

 

p.15 first sentence below the bulleted list.  I don't think we should allow unqualified further values to be added.  We should use the same QName condition that is used for extensions to the value of 'label'.

 

<JD> but that looks bad when you display the set of possible values in a test report: you don't want some to be qualified and some not. In tamelizer open source, we use a few extra values like "warning", "missingInput", etc. Frankly I don't want to qualify these... One way out is to add/define these in TAML spec as additions that @label *may* allow (so they remain unqualified, and everything beyond these must be qualified). Otherwise if we unqualify all extensions, it appears we need to do same for prescription/@level extensions. At the very least, @lable should not be NCName but normalizedString (if it is to accept either qualified or unqualified extensions).

 

pp.14.    <taml:tag> is an element.  I just noticed that it has an @name attribute.  Is this defined the same way as the other use of @name, and if not, shouldn't we differentiate them (for future cases where we want to allow taml:name in non-TAML instances, such as RDF).

 

<JD> So it appears that we may have to rename:

Tag/@name --> tag/@tname

var/@name --> var/@vname

testAssertionSet/@name --> testAssertionSet/@setname (we already have @setid)

 

 

I think this should reference section 2.5.

 

<JD> good point - in fact, I noticed that the text used for 2.5 in the markup is already in the TA model (3.2.12, with Tag subsection), so a brief recap in the markup taml:tag section is sufficient, with a reference to the Model section. Then we can entirely remove Section 2.5.

 

pp. 17-18.  Section 2.5.1  I don't understand how or why we are lapsing into this notation, which is not used anywhere else for TAML.

 

Shouldn't we just say that NormativeProperty is a reserved taml:tag/@name value, and what the text of the element signifies?

 

LIkewise with 2.5.2.  And in the definition for taml:tab/@name="VersionDrop" I think the definition is not accurate (e.g., a number lower than VersionAdd would qualify).  Perhaps "the numerical version number, if any, beyond which the test assertion does NOT apply".

 

 

 

  ** end of second-review notes **

 

 

---------------------------------------------------------------------

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]