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

 


Help: OASIS Mailing Lists Help | MarkMail Help

emergency-comment message

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


Subject: Comments on CAP V 1.1




Hello - some comments on CAP V 1.1 (Subcommittee Draft - 4 Jan 2005)

1) Section 3.2.1 - Page 10 - "alert" row of table

The xmlns attribute referencing the CAP Namespace URI should
not be a "MUST" as this is not consistent with the XML Namespace rules.
The CAP Namespace URI can occur on any element before it is actually 
used.
If you use CAP with other XML (eg SOAP) you probably would put ALL XML 
Namespaces
at the beginning.

2) Section 3.2.1 - Page 10 - "identifier" and "sender" rows of table

I would strongly urge the use of URI's [1] as the mandatory scheme for 
identifying
these entities. For a "number or string" to be unique will require a 
more formal
definition. The <identifier> examples in Appendix A do not show any 
mechanisms for
being unique.

3) Section 3.2.2 - Page 13 - "language" row of table

I would strongly urge the use of xml:lang [2] to indicate the language 
of
element content. I would also not support the use of a default value as 
this
is not consistent with open internationlisation.

4) Section 3.2.2 - Page 15/16 - "eventCode" and "parameter" rows of 
table

Have you considered using XML as the syntax for the content of these 
elements?
It makes more sense to use the same syntax and processing rules for XML.
This would allow the additional information to appear as XML and abide 
by the
XML rules. So, the following:

<cap:parameter>Depth=11.8mi</cap:parameter>
<cap:parameter>Quality=Excellent</cap:parameter>

Would be represented as:

<cap:parameter>
   <my:Depth unit="mi">11.8</my:Depth>
   <my:Quality>Excellent</my:Quality>
</cap:parameter>

Hence - the extra semantics (as defined in XML Schemas) could the be 
reused and
also provide more details (eg the attributes).

5) Section 3.2.2 - Page 16 - "contact" row of table

Have you considered using a more structured value for the Contact 
details
such as vCard or xNAL [3] ?
This would allow phone numbers, email addresses to be automatically 
accessible.


Cheers...

Dr Renato Iannella
Project Leader, NICTA, Brisbane, QLD, AUSTRALIA
P: +61 7 3000 0484 F: +61 7 3000 0480 M: +61 4 1313 2206
E: renato@nicta.com.au W: http://nicta.com.au

[1] <http://www.ietf.org/rfc/rfc3986.txt>
[2] <http://w3.org/International/articles/language-tags/>
[3] <http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ciq>


--------------------------------------------------------------------------
This email and any attachments are confidential. They may contain legally
privileged information or copyright material. You should not read, copy,
use or disclose them without authorisation. If you are not an intended
recipient, please contact us at once by return email and then delete both
messages. We do not accept liability in connection with computer virus,
data corruption, delay, interruption, unauthorised access or unauthorised
amendment. This notice should not be removed.


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