RE: [tag] ID consistency

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

I think that, while the values of the testAssertion/@id and testAssertionRef/@id are from the same domain, they are not semantically the same.  It is the testAssertion/@id that is required to be globally unique and the attribute establishes the assertion that has that identifier.  The testAssertionRef/@id does not establish an identifier, it references the testAssertion for which the testAssertionRef/@id has that value.

These are semantically different - one is a foreign key, the other is a primary key as it were.

I think testAssertionRef/@id should be named in a way that distinguishes it as a reference apart from the element name (for reasons of namespace clarity). 

I concur about testAssertionSet/@setid and I wonder if its uniqueness is in an independent domain (having the same nominal value set) from testAssertion/@id or do we have a single domain across which they need to be unique.  I tend to favor the latter, even though testAssertionRef/@id (however renamed) cannot refer to a set and if we ever have a setref I presume it can only refer to the @setid value of a testAssertionSet.

Looking at your proposed consistency change, I would do this:

Leave testAssertion/@id as the primary key identifier of the testAssertion

Use testAssertionRef/@toid for the id of the referenced testAssertion

Use testAssertionSet/@setid as the primary key identifier of the testAssertionSet and use the same datatype and specify that it is the single nominal identifier domain in which all ids must be distinct.  (For two domains, the semantic conditions on uniqueness are restated and there is now no ref that can refer to either kind).

Use @tosetid if we ever need a (foreign-key) way to reference a testAssertionSet by its identifier.

 - Dennis

-----Original Message-----
From: Jacques Durand [mailto:JDurand@us.fujitsu.com] 
Sent: Sunday, May 15, 2011 12:54
To: tag@lists.oasis-open.org
Subject: [tag] ID consistency

Here is the latest proposal to bring consistency to "id" attribute names, so as to cause minimal disruption and preserve backward compatibility of existing instances of markup:

In the markup:

- keep testAssertion/@id, but rename testAssertionRef/@taid as testAssertionRef/@id (as these @id are all TA ids)
- rename testAssertionSet/@id as testAssertionSet/@setid

That way, @id in our markup always means TA identifier.

This on top of the clean-up that removed the "language" attribute in the Model from testAssertion and from other normative source elements, and keeps it only on some key elements (predicate, target, prereq...) that are most likely to use expressions in their content. Note that in the Markup testAssertion/@lg is still there as an extension (to the model), to define a default for all subelements that have @lg.

If no objection, I will upload corresponding drafts as next candidates this Monday.

-jacques


-----Original Message-----
From: Jacques Durand [mailto:JDurand@us.fujitsu.com]
Sent: Friday, May 13, 2011 4:04 PM
To: dennis.hamilton@acm.org; tag@lists.oasis-open.org
Subject: [tag] RE: Handling of the TAML Namespace

Thanks Dennis:

(1)(2): we can escalate this to TC admin - this ns doc can always be fixed separately.
(3)(4)(5): right. I could see the @lg attribute being shared, and indeed now that we have removed it from all "normative src" elements and other external doc refs, the remaining @lg have all same meaning (identify an expression lge).
- The @id is used both on testAssertion and testAssertionSet, therefore not exactly same def (not identifying same type of object). 
Now on testAssertionRef we have @taid, which has exactly same meaning as testAssertion/@id...

So for consistency (and for (5) ) we could rename our TA @id: testAssertion/@taid. (which would also make for a more identifiable attr name)

Opinion?

Jacques

-----Original Message-----
From: Dennis E. Hamilton [mailto:dennis.hamilton@acm.org]
Sent: Thursday, May 12, 2011 8:41 PM
To: Jacques Durand; tag@lists.oasis-open.org
Subject: Handling of the TAML Namespace

In thinking about the ID question, I also had a thought about the namespace established for TAML, http://docs.oasis-open.org/ns/tag/taml-201002/


I notice the following about the namespace document:

1. It doesn't name the namespace (although it is at the place where the namespace resolves).  It should do so in the Introduction line.

2. It doesn't say how one determines what the components of the namespace are.  That is, it refers to the W3C Schema for TAML.  (It also refers to the TAML specification, but that doesn't directly describe the namespace either).

I know (2) is typical, but I think that is because the "template" for namespace documents doesn't include any pro forma for what a namespace might cover.  So people just use the template and do nothing more.  That is not what happens where namespaces are defined in other specifications (such as W3C and DCMI specifications).

3. The attributes that have no namespace in TAML have no namespace.  That is, they are not available in the namespace.  They are only available on the TAML elements where they are defined as admissable attributes by the schema.

4. To allow for expanded use and for re-use of TAML, it is not unusual to add the attributes to the namespace, but to forbid them being used with the namespace prefix in TAML elements.  That is, there are two forms for the TAML attributes, one without the namespace and used with TAML elements and ones with namespace bindings that are for use elsewhere.  Examples include in some other markup that borrows those elements, in RDF (where a namespace is required), and in XHTML.  (There are XHTML attributes defined this way also, and it is how RDFa gets XHTML attributes to use outside of XHTML documents.)

5. However, to do (4), each such attribute has to have a context-independent definition.  That is, whatever TAML elements that have an attribute of the same name, a single definition works for all of those occurrences.

Because of the amount of additional documentation that it takes to have (4-5) work, I do not propose that we go this far with TAML 1.0.

HOWEVER, we should probably make sure that (5) holds so that we have the option in the future.

 I have not checked to see what this impacts, if anything.  We know there were variants of the @lg that might have been impacted.  But I haven't reviewed the current draft to see if there is anything that might be worth cleaning up.

  - Dennis