Comments on DPF Draft

0 comments responded to
0 comments unresolved
53 comments finished
Status key: 'U' unresolved, 'R' responded, 'F' finished.
Type key: 'E' editorial, 'S' substantive.

# Status SectNameKDSRMAll
1Fs2Use of word Properties in listXXXXXX
2Fs2identifiers vs expressionsXXXXXX
3Fs2'hierarchy' of properties, or tree of property/value pairsXXXXXX
4Fs2names are in namespaces, not anything elseXXXXXX
5Fs4.1Figure 1 confusingXXXXXX
6Fs4.1.4Wording last paraXXXXXX
7Fs4.2Exception text muddleXXXXXX
8Fs4.2.4last sentence misses casesXXXXXX
9Fs4.2.7Figure 2 first box labelled GPS not in namespaceXXXXXX
10Fs4.3INDEX_SIZE_ERR or INVALID_ACCESS_ERRXXXXXX
11Fs7Date in ECMASCript refXXXXXX
12Fs4.1.3Section 4.1.3XXXXXX
13FA1Awkwardness of XPath or ECMAScript expressionsXXXXXX
14Fs2Incompleteness of ECMAScript bindingXXXXXX
15Fs2XPath expressions over propertiesXXXXXX
16Fs2Colon (:) in identifiersXXXXXX
17Fs4.2.7Identical names in different namespacesXXXXXX
18Fs4.1.4Add/remove events should be defined in DPFXXXXXX
19Fs4.2.1Metadata is unusableXXXXXX
20Fs4.2.2NOT_FOUND_ERRXXXXXX
21Fs4.8SYNTAX_ERRXXXXXX
22FGeneralTYPE_MISMATCH_ERRXXXXXX
23Fs4.1.2inconsistency needs discussionXXXXXX
24Fs4.2.7wildcards in hasDPFPropertyXXXXXX
25Fs4.2.7NULL as wildcard?XXXXXX
26Fs4.3item(335) INVALID_ACCESS_ERR or NULLXXXXXX
27Fs4.3.24.3.2 exception on removal better?XXXXXX
28Fs5Event categories underspecified in section 5XXXXXX
29FGeneralLanguage considerationsXXXXXX
30FGeneralProperties with both values and child properties?XXXXXX
31Fs4.2.7DPFProperty hierarchies as RDF GraphsXXXXXX
32Fs4.2.7Is the order of children importantXXXXXX
33FGeneralTree or Graph?XXXXXX
34FGeneralInteroperability aspirationsXXXXXX
35FGeneralProperty definitions etc.XXXXXX
36FGeneralConstraining the use of properties to certain typesXXXXXX
37FGeneralRelationship with Delivery ContextXXXXXX
38FGeneralData ModelXXXXXX
39FGeneralAbstractionXXXXXX
40FGeneralData TypesXXXXXX
41Fs.4.3.1The Live DPFPropertyListXXXXXX
42FGeneralProcessing ComplexityXXXXXX
43FA2ExamplesXXXXXX
44FGeneralStatic vs DynamicXXXXXX
45FGeneralSpecific PropertiesXXXXXX
46FGeneralImplementation investment and page size determinismXXXXXX
47FGeneralRelation to RDF propertiesXXXXXX
48Fs3Are there any RDF properties which cannot be used as DPF properties?XXXXXX
49FGeneralCan any/all/some DPF properties be used as RDF properties?XXXXXX
50FGeneralAre there any DPF properties which cannot be used as RDF properties?XXXXXX
51Fs4.2.7Cardinality and propertyXXXXXX
52FA2Property DeclarationsXXXXXX
53FGeneralDefining event types in terms of DPF-based expressions?XXXXXX
#StatusDescription/Response
1FUse of word Properties in list( s2, HP, editorial comment e1 )

The word 'Properties' is used in two different ways, in a confusing manner in the numbered list. In point 1 it is used to refer to the property as a relationship between things, an abstraction. In points 3 and 6 what seems to be being discussed is property values (in particular instances)

Suggest s/Properties/Property values/ in points 3. and 6.

Response:

31st March 2005: change made to WD

April 7th 2005: Sailesh pointed out that point 6 needs to be about "properties" not "property values" therefore reverted modification.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
2Fidentifiers vs expressions( s2, HP, editorial comment e2 )

(section 2.2) In the last sentence of this point the word identifier is used to refer to a name with no punctuation. In the examples in the first sentence expressions such as "a.b.c[2]" are misreferred to as identifiers (I see three identifiers in that expression). Suggest s/ such as/, for example,/

Response:

31st March 2005: section removed. Note: Unless we decide to include such 'shortcut' expressions within a normative ECMAScript binding.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
3F'hierarchy' of properties, or tree of property/value pairs( s2, HP, editorial comment e3 )

(also throughout doc, particularly first para 4.1)

I found the term hierarchy confusing; perhaps being an RDF-head, I thought you might have been talking about sub-properties etc. Suggest using a word like tree instead, and at some point clarifying that we are talking about a tree of property/value pairs.

Response:

April 7th 2005: The DPF WG disagree with CR. Trees and hierarchies are well understood terms in Computer Science and are often used interchangably. However, one modification to section title: 4.1 Dynamic Properties Framework Property "Tree" to become "Hierarchy".


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
4Fnames are in namespaces, not anything else( s2, HP, editorial comment e4 )

(section 2.1) Namespace in XML says:

"An XML namespace is a collection of names"

To suggest that other things are in namespaces is a mistake. Suggest that the wording of point 1 start something like:

"Properties are named. The name of a property is in an XML namespace."

Response:

The DPF WG agree. There is a slight modifications, so this now reads: "Property names are associated with XML namespaces and can be arranged in hierarchies. This enables properties to be defined by multiple organizations without fear of name conflicts."


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
5FFigure 1 confusing( s4.1, HP, editorial comment e5 )

I got really quite confused by figure 1 and the text above it. I only really made sense of it when I had read further in the document. In part this was that I hadn't work out what you meant by hierarchy by this point. In part this is that the label "DPF Component" seems to describe the type of that rectangle, whereas the labels "Property [A-C1-6]" seem to be being used to name the relationship between the labelled rectangle and the rectangle above. The lines are also working quite hard, and looking at the picture again I think perhaps too hard. (The lines are representing both the parent/child relationship and the sibling relationships)

I guess I'm really looking for substantive changes here, so my suggested fix is in a different comment (mainly comment r2)

Response:

March 31 2005: The issue with Figure 1. meaning of hierarchy related to CR 2. This is a link to the figure that Jeremy Carroll proposed: http://lists.w3.org/Archives/Public/www-multimodal/2005Jan/att-0002/fig2.pdf

April 7 2005: DPF WG agreed not to change the figure. Agreed that we need words to support the fact that this WD focuses on describing a set of interfaces and not RDF ontologies. As a result we want to clarify property hierachies rather than property ontologies. This relates to a a further review of new section: Meta Data 4.1.5.

April 28th 2005: (Text response suggestion) Such semantic representations are possible, but out-of-scope. The DPF is not a model to MetaData. Futher, the DPF does not need a semantic representation to function and there is no means to describe such representations in the WD. Having said this, it is possible to capture such representations via the metaData interfaces.

May 17th 2005: Generated newer version of Figure 1 to reflect non-relationship - if desired - for the properties A1 .. C2.

May 18th 2005: Generated newer version of Figure 1 to reflect the naming conflict for the DPF Component. It now reflects a generic Root node.

May 19th 2005: Generated newer version of Figure 1 to reflect the naming conflict for the DPF Component. It now reflects a generic "Root Property". This should be checked with the DIWG (Roland) for sanity. An alternative would be "Root Context".

May 20th 2005 text response: Figure 1. has been redesigned to take into account the "Property [A-C 1-6]" issue. Figure 1. (attached) now illustrates leaf nodes as "Property [A1, A2]" and "Property [C1, C2]" to clarify their non-relationship.

While semantic representations are possible, the DPF considers this to be out-of-scope. The DPF focuses on describing a set of interfaces not RDF ontologies. As a result, the intent of Figure 1. is to clarify property hierachies rather than property ontologies. The DPF is not a model to MetaData. Further, the DPF does not need a semantic representation to function and there is no means to describe such representations in DPF. Having said this, it is possible to capture such representations via the metaData interfaces.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
6FWording last para( s4.1.4, HP, editorial comment e6 )

I found the wording here confusing, I started looking for more information elsewhere (e.g. in the appendixes) concerning these examples.

Suggest: old [[ Informative examples are given to explain how this works, for example ]] new [[ Some informative examples are:]]

Response:

April 5th 2005: Agreed, edit done.

May 18th 2005: Removed strike-out text and made text final.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
7FException text muddle( s4.2, HP, editorial comment e7 )

There seems to have been a number of editorial errors with the text defining the conditions leading to exceptions.

A glaring copy/paste one is last sentence of 4.2.5 the property in question has no previous parent, this text seems to have been miscopied from 4.2.4

A large number of exceptions have no text describing when they happen in a particular method.

I suggest significant effort to clarify here. I would like to see, under each method, a table, with one column with the exception, and a second with a description of the exception condition as it occurs in this method.

While such text would be boring (both to write and to read) and would duplicate (to some extent) section 4.8, I think it would be helpful and clear.

I also have a number of substantive issues (s8, s9, s10, s14, s15) to do with exceptions, which I believe stem partly from the lack of clarity of the current text leading to mistakes.

Response:

April 7th 2005: this should be taken care of in the upcoming large exception update. Sailesh and Matt to work though the exceptions and reconciling the text "no text".

May 26th 2005 Text response: The exception sections have undergone significant updates and several editorial as well as logical errors have been corrected as a result. We have removed exceptions that do not fit within the method context as well as added new exceptions that could arise during interface usage. The explanations for these exceptions have been updated/added. Each exception has been explained in the latest draft within each interface context and a seperate section listing all the exceptions including general definitions for these has been added.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
8Flast sentence misses cases( s4.2.4, HP, editorial comment e8 )

Are there not four cases which can raise a NO_MODIFICATIONS_ALLOWED_ERR? newChild is read only oldChild is read only this property is read only the previous parent of oldChild is read only the text only identifies two of these.

Response:

Text posted June 2nd 2005 ("http://lists.w3.org/Archives/Public/www-di/2005Jun/0008.html"): The DPF Working Group agrees, and have been working through the document to address exceptions more comprehensively.

With respect to the particular Interface 4.2.4 replaceDPFFProperty is is now 5.1.2.3 replaceDPFProperty and is defined as follows:

DPFProperty replaceDPFProperty(in DPFProperty newChild, in DPFProperty oldChild) raises(DPFException);

This method is used to replace an existing child property with a new child property. The new child's parent data item is set to this property. If it was previously the child of another property, it will be automatically removed from that property before being added to this one.

Parameters

newChild

The new child property that will replace an old child property.

oldChild

The old child property that will be replaced by a new child property.

Return Value

DPFProperty The return value is the property being replaced. The return value is the new child property that replaced the old child property. If an error occured during the operation, the value NULL is returned.

Exceptions

DPFException

NO_MODIFICATIONS_ALLOWED_ERR: This exception is raised if the current parent property under which a child property is being replaced is read only and cannot be modified.

HIERARCHY_REQUEST_ERR: This exception is raised if the child property that replaces the old property do not belong to the property type supported by the parent, if the child property is an ancestor of the current parent property or a replica of the current parent property itself.

NOT_FOUND_ERR: This exception is raised if the old child that is being replaced by the new child is not a child of the current parent property.

TYPE_MISMATCH_ERR: This exception is raised when there is a DPF object type mismatch between the parent, new child and old child being replaced. For example, adding a DPFPropertyList when a DPFProperty is expected.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
9FFigure 2 first box labelled GPS not in namespace( s4.2.7, HP, editorial comment e9 )

Suggest replacing "GPS" with "EG:GPS" All property names are in namespaces.

Response:

April 29th 2005: Dave to add "e.g.,GPS" to figure.

May 17th 2005: New figure 2 created with "Example: GPS"

May 18th 2005: New Figure 2 created with "A/B/C: GPS" rather than Nokia and IBM nodes for clarity. Also removed the DPF Component and replaced as a root node.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
10FINDEX_SIZE_ERR or INVALID_ACCESS_ERR( s4.3, HP, editorial comment e10 )

(also section 4.8) Do these two errors mean the same thing? (Sorry again overlap with substantive comment, s14 concerning text of 4.3)

Response:

May 18th 2005: This will be taken care of in the upcoming large exception update.

May 26th 2005: Text response: No. The errors do not mean the same thing. These exceptions apply to the Item() method within the DPFPropertyList interface. The Item() method returns a DPFProperty within the property list based on an index (size of list) value. The INDEX_SIZE_ERR is raised if an invalid size number is used as a parameter to item call. The INVALID_ACCESS_ERR is raised due to an invalid memory access that occurs after a DPFProperty was accessed from the list. For example, a script object would have accessed the value pointer of a DPFProperty node from the property list. Now the property was removed from the list. If the script object tries to access the value pointer (that was stored in the previous call), this exception would be raised.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
11FDate in ECMASCript ref( s7, HP, editorial comment e11 )

Please include the date for this reference. It would have been helpful. (I know it's only a click away, but we were looking at a printed version...)

Response:

May 18th 2005: agreed, edit made.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
12FSection 4.1.3( s4.1.3, HP, editorial comment e12 )

This does not specify anything, but reads more as an apology by the working group for not having provided a solution for access rights and validation. As such, it seems inappropriate in a recommendation, and should simply be deleted (the whole section).

Response:

May 11th 2005: decided to remove old text, now the new text reads: "The Dynamic Properties Framework is designed to provide direct access to properties even though they may be represented by particular vocabularies originating in different specifications and organizations. DPF concentrates on interfaces by which access to characteristics are obtained in programming environments, rather than on mechanisms used to represent the information. As a result, DPF provides a level of insulation from specific representations. The DPF may well encompass ontology's for device properties and characteristics defined by other working bodies (for example [OMA]) and is therefore outside the scope of DPF. However, it is the intent of the Device Independence Working Group [DIWG] to specify representations of ontology's through [OWL], as well as presentation characteristics through Core Presentation Characteristics [ref-CPC]. Consequently, the DPF provides mechanisms to access device properties and characteristics whose ontology's and accessing interfaces are specified elsewhere."

May 18th 2005: Normative and Informative sections added to references as well as the associated text: "... as well as presentation characteristics being developed by the through Core Presentation Characteristics work item activities. Consequently, the DPF provides mechanisms to access device properties and characteristics whose ontology's and accessing interfaces are specified elsewhere."


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
13FAwkwardness of XPath or ECMAScript expressions( A1, HP, substantive comment s1 )

In Appendix A DPFProperty is not related to a DOM element. However, in Appendix B and in section 2 numbered point 2, expressions in XPath and ECMAScript are presented that involve navigating the tree of properties as if it were a tree of XML elements. This results in a number of related bugs.

Response:

March 31st 2005: Section 2.2 has been removed due to the ambiguitiy of the ECMAScript expressions. It is possible that a DPF implementation would allow such expressions, but support for these expressions are no longer required by the DPF.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
14FIncompleteness of ECMAScript binding( s2, HP, substantive comment s2 )

The intent in section 2 point 2 is that ECMAScript expressions such as "a.b.c[2]" should interact with the specification of DPF. It is not specified as to how this is done.

Response:

March 31st 2005: the section has been removed (note: Unless we decide to include such 'shortcut' expressions within a normative ECMAScript binding.)

April 7th 2005: Section 2.2 removed.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
15FXPath expressions over properties( s2, HP, substantive comment s3 )

The intent in section 2 point 2 is that XPath expressions such as "/a/b/c[3]" should interact with the specification of DPF. It is not specified as to how this is done.

Response:

Rhys has presented an initial rough commentary on XPath to the mailing list. Needs discussion at f2f.

April 7th 2005: Section 2.2 removed. Related to CR 2.

June 3 2005: I sent out a response saying that 2.2 has been removed from the WD. However, it still leaves the issue of XPath bindings expecially for the example in B.2? Also where is this text from Rhys? (can't find it). Appendix B.2 describes XPath expressions.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
16FColon (:) in identifiers( s2, HP, substantive comment s4 )

Section 2 point 2 defines the set of valid property names in a way that excludes :. This leaves it unclear as to how namespace information should be included in XPath expressions or ECMAScript expressions that navigate a DPFProperty tree.

Response:

April 11th 2005: section 2 point 2 has been removed. Rhys has also presented an initial rough commentary on XPath to the mailing list. Needs discussion at f2f.

June 3rd 2005: I have responded saying section 2 point 2 has been removed from the WD. However, as with C15 I think we need to explain ourselves as to why we don't describe XPath or ECMAScript bindings.

June 8th 2005 addtional comments at f2f: No XPath because it is out-of-scope. Perhaps a seperate document. XPath function document perhaps?


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
17FIdentical names in different namespaces( s4.2.7, HP, substantive comment s5 )

Figure 2 presents the possibility of the use of identical names in different namespaces. The intent appears to be that DPF should provide a framework in which different properties independently defined by different namespace owners can interoperate. However, the ECMAScript expressions are unable to distinguish namespaces and the semantics of an expression like "gps.gps" is unclear for figure 2.

Response:

June 3rd 2005: Figure 2 has been modified to clarify the namespacing as well as the associated text that now read:

Search results may contain properties with the same name and namespace values and so appear to be identical. In order to disambiguate between the two, it is neccessary to compare their parent nodes. For example, there could be two or more GPS systems present with the inter-relation show in Figure 2.

[figure 2] Figure 2. An example GPS hierarchy.

For example, if getDPFPropertyList were called on the node pictured above named C:GPS, with a namespaceURI parameter set to NULL, a propertyName parameter set to "GPS", and a deep parameter set to "true", the DPFPropertyList returned would contain two properties with a namespace of A and a name of GPS. These nodes could be disambiguated by comparing their parent attributes.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
18FAdd/remove events should be defined in DPF( s4.1.4, HP, substantive comment s6 )

Penultimate para of 4.1.4 leaves open whether add/remove events should be standardized. It seems to be that they should, since they are needed and generic, and a lack of standardization is an easily avoidable interoperability failure.

Response:

April 11th 2005: DPF WG agree, addDPFEventListener and removeDPFEventListener are in the WD and IDL.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
19FMetadata is unusable( s4.2.1, HP, substantive comment s7 )

The end of 4.2.1 provides a metadata interface, but with no indication of what are the legal values for either of the two attributes they are unusable - they have no semantics. My preference is to delete these attributes and say that metadata about a property (i.e. the concept that is being used, rather than the value of the property in this particular context) should be provided in RDF/XML at the URI created by concatenating the namespaceURI with the name (as in RDF/XML).

Response:

April 14th 2005: Added new revised text (Dave R).

Response text:

The DPF is a framework that is designed to be complemented by additional specifications for specific properties. These specifications would be able to cover the kinds of meta data and their representation. The DPFMetaDataExtInterface interface provides a general extension mechanism for directly associating meta data with DPF properties in terms of a pointer to an interface used to reference metadata, and a DOMString used to identify the type of that interface.

An alternative would be to omit DPFMetaDataExtInterface with the idea of leaving it up to specific properties to define their own property specific interface for referencing meta data.

For mobile applications, a general RDF based solution may not be practical in all situations. Both RDF and OWL could however be used for describing properties e.g. for the purposes of authoring solutions, although this is beyond the scope of the current specification.

To clarify the specification, we have added a new section 4.1.5 and expanded section 4.2.1.

March 31th 2005: Added new section 4.1.5 and provided more description to section 4.2.1. Note:

We had earlier defined a seperate interface for metadata that had attributes such as time, version no, extended interface etc. The reason this was thrown out was there was the feeling that such an interface would be an overkill for each property and that certain attributes could be added directly to DPFProperty interface rather than through a new interface (thrown out for the same reasons mentioned).

It was decided that we would have a metadatainterface that would be specific for each property. The format and information contained would be property specific and would be defined elsewhere.

Also, I am uncomfortable with specifying an RDF based interface for metadata even though this may be the most standard deployment. It should be possible to classify properties that use RDF specific extensions and others that are vendor specific.

For a better DPFMetaDataExtInterfaceType definition (To quote Dave): "This attribute describes the type of interface (DPFMetaDataExtInterface) that may exist to describe additional information about the property. The type supported is property specific."

We could add the above line to 4.2.1 for additonal clarity.

http://lists.w3.org/Archives/Member/w3c-di-wg/2005Feb/0019.html

June 3rd 2005 Text response: To address this Meta Data issue, following section 4.1.5 Meta Data has been added to the WD.

4.1.5 Meta Data

Meta data can be directly or indirectly associated with DPF properties. Some potential examples of interesting meta data include the version of a property interface, and timestamps for property creation and modification. Richer meta data could describe ontologies of properties, and be expressed using powerful meta data frameworks like OWL [OWL] for the purposes of authoring solutions.

Note that the kinds of meta data and their representation is outside the scope of this specification. The DPFMetaDataExtInterface interface provides a means for accessing meta data directly associated with a property, in terms of a pointer to an interface for the meta data and a DOMString value identifying the type for that interface.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
20FNOT_FOUND_ERR( s4.2.2, HP, substantive comment s8 )

In 4.2.2 The method signature of appendDPFProperty appears to be incorrect in that NOT_FOUND_ERR cannot occur.

Response:

18th May 2005: this will be taken care of in the upcoming large exception update.

26th May 2005 response: Agreed. The NOT_FOUND_ERR cannot occur within appendDPFProperty. The current draft reflects this and the exceptions that are raised here are NO_MODIFICATIONS_ALLOWED_ERR, HIERARCHY_REQUEST_ERR, and TYPE_MISMATCH_ERR.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
21FSYNTAX_ERR( s4.8, HP, substantive comment s9 )

It's very unclear what this means. What syntax has been violated? The description in 4.8 talks about 'invalid or illegal' (what's the difference between 'invalid' or 'illegal') strings. The exception appears on many methods with no string arguments, and does not appear in searchDPFProperty.

Response:

May 18th 2005: this will be taken care of in the upcoming large exception update.

May 26th 2005 response: The usage of SYNTAX_ERR has been modified in the current draft. The definition for SYNTAX_ERR states that this exception is raised when the syntax for namespaceURI or propertyName do not conform to the syntax supported by the DPF platform. The SYNTAX_ERR can be raised by the methods hasDPFProperty(), getDPFPropertyList(), and searchDPFProperty() where the usage of syntax is valid.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
22FTYPE_MISMATCH_ERR( General, HP, substantive comment s10 )

property type

No definition of property types is given and so both these concepts used extensively are coherent. This should be fixed somehow. See my RDF related comments for my suggestion as to how.

Response:

The question asked here is: how does TYPE_MISMATCH_ERR ever get thrown if there are no types for properties? The answer is, I think, that when we expect a DPFProperty and we get a DPFPropertyList as parameters, or vice versa, or some other combination of DPF types, we throw this exception.

Added DPFPropertyType has been added: http://www.w3.org/2001/di/Group/di-dpf/#DPFProperty as well as supporting text.

May 26th 2005 response: The TYPE_MISMATCH_ERR has been re-defined. This exception is raised when there is a DPF object type mismatch between a parent and a child property. For example, adding a DPFPropertyList when a DPFProperty is expected.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
23Finconsistency needs discussion( s4.1.2, HP, substantive comment s11 )

Section 4.1.2 describes the use of DPF in distributed systems. Within these, latencies are such that inconsistency is likely. The DPF specification should take a position such as inconsistent values may be returned to the application, and the application has to deal with it, or that given some appropriate additional methods the application can get a consistent snapshot of the state.

Response:

June 8th 2005 text response: This is not a unique problem to DPF and there is no guarentee of service. Also, there will always be some level inconsistency and has to be delt within the application space.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
24Fwildcards in hasDPFProperty( s4.2.7, HP, substantive comment s12 )

Is it a mistake to have omitted the use of the wildcards in 4.2.7 from 4.2.6 hasDPFProperty? Since implementors need to write the code anyway, they may as well apply in both methods.

Response:

11 April 2005: DPF WG agree, new text as follows, for both hasDPFProperty and getDPFPropertyList:

namespaceURI:

The namespaceURI parameter is a DOMString containing the namespace of the property being searched. The namespaceURI string may be empty, which denotes a 'wildcard', i.e., it matches any namespace found.

propertyName:

The propertyName parameter is a DOMString containing the name of the property being searched. The propertyName string may be empty, which denotes a 'wildcard', i.e., it matches any property name found.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
25FNULL as wildcard?( s4.2.7, HP, substantive comment s13 )

In section 4.2.7 NULL is used as the wild card. Wouldn't "*" be better, to avoid misinterpreting programmar error resulting in null pointers.

Response:

Wildcard character may depend on the binding, strip the use of NULL, mention that this is dictated in the binding.

8th June 2005 text response: The DPF uses empty string to mean a property with no namespace, * to mean a property in any namespace. Therefore, a query with namespace of "" and name of battery would find only items without namespaces.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
26Fitem(335) INVALID_ACCESS_ERR or NULL( s4.3, HP, substantive comment s14 )

Section 4.3 declares an INVALID_ACCESS_ERR on the item() method, but does not specify it's use. Rather the specification is to return NULL. I suggest the specification should be changed to throw an INVALID_ACCESS_ERR when the index is out of range.

Response:

May 18th 2005: this will be taken care of in the upcoming large exception update.

May 26th 2005 response: The Item() method returns a DPFProperty within the property list based on an index (size of list) value. If an invalid index number is used, an INDEX_SIZE_ERR is raised. The INVALID_ACCESS_ERR is raised due to an invalid memory access that occurs after a DPFProperty was accessed from the list. For example, a script object would have accessed the value pointer of a DPFProperty node from the property list. Now the property was removed from the list. If the script object tries to access the value pointer (that was stored in the previous call), this exception would be raised. The DPFPropertyList always reflects the state of the properties within the list i.e they are live. If a property is removed from the system, the corresponding entry within the list points to an empty node.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
27F4.3.2 exception on removal better?( s4.3.2, HP, substantive comment s15 )

I was surprised that accessing a property that has been deleted is not an exception. If the WG has already considered and rejected such a design choice, this comment is already adequately addressed. Otherwise please consider it.

Response:

See f2f minutes

May 26th response: The WG did consider this issue relating to properties within a DPFPropertyList. When the property list needs to be live, this poses certain problems. Considering the issues that may be raised, it was decided that the best way to maintain the states within the property list would be to point a property entry to a NULL node if it was removed. If the value of the node was accessed by the calling application and then the property was removed (thereby the application uses the stored value to access it again), then an INVALID_ACCESS_ERR exception would be raised.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
28FEvent categories underspecified in section 5( s5, HP, substantive comment s16 )

The fifth para of section 5 sketches the use of wildcards to create event categories. This sketch is insufficiently complete to build interoperating implementations.

Response:

The DPF team would like to inherit the DOM 3 event interfaces, however at the time of this writing the DOM 3 events was a Note vs a specification. As such, we decided to defer inheriting the interfaces until a W3C group picked up the DOM 3 interfaces and moved on from a Note stage to a draft stage.

I believe Dave Ragett had an action item (not last week rather the week before) to speak to the DOM people asking them what is the status of this work.

April 31st 2005: text response: The DPF WG acknowledge the ambiguity in using wildcards to specify event categories and as such have modified the notion of event categories and their usage in section 5 to be more in line with the DOM 3 Event Note. The text now reads:

An event category is represented by a namespace URI and a local name. Event categories allow listeners to be registered for a hierarchy of DPF events rather than for a specific event type. For example, events denoting an asr connection status can be associated with the following three categories {"http://www.example.org/2003/voicexml", "connection"}, {"http://www.example.org/2003/voicexml", "connection.disconnect"} or {"http://www.example.org/2003/voicexml", "connection.disconnect.hangup"}. An event listener that wishes to be notified on the overall status of an asr connection would register for the first category of events, and would thus be notified upon asr engine being connected, disconnected, and when disconnected if it was a hangup or not. On the other hand, an event listener that wants to be notified only on hangup calls would register for the last event category.

For the type in the methods addDPFEventListener and removeDPFEventListener the text is as follows:

The type parameter specifies the type of event for which the listener wants notification. This paramenter can also be used to register for category of events, rather than for a specific event; this assumes that event categories are expressed as a hierarchy of names. See Section event process model for examples of event categories.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
29FLanguage considerations( General, HP, substantive comment s17 )

The specification of DPF provides no capabality to add language tagging to string values of DPFProperties.

Response:

We may want to add a paragraph describing the strings used within DPF as machine readable, and that if they're human readable that is a side effect.

June 3rd 2005 text response: As we re-enter last call we'll seek a review from Internationalization WGs.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
30FProperties with both values and child properties?( General, HP, RDF comment r1 )

The specification of a DPFProperty allows for a property to have both a value and to have children. No examples of the use of this feature is shown. It would be less confusing to have two different subinterfaces of DPFProperty: one that had a value but no children, the other that has (possibly 0) children, but no value. In the latter case, it then seems that the collection of children of a DPFProperty describe an (unnamed) resource that is the value of the parent DPFProperty, e.g. in Figure 2, the property "GPS" has a (resource) value that is described with two properties "IBM:GPS" and "NOKIA:GPS"

Response:

17th May 2005: Diagram has been updated to reflect A/B/C:GPS. This diagram is not intended to illustrate a RDF graph structure.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
31FDPFProperty hierarchies as RDF Graphs( s4.2.7, HP, RDF comment r2 )

We redrew fig2 as in the attached PDF file.

We simplified the lines, so that they just show parent/child relationships, and not sibling relationships.

We added arrows to the lines rather than relying on the vertical convention of parents above children.

We clarified that the labels (except DPF component) were describing the relationship between parent and child, rather than describing the child

We also added a little bit more, to show how a value could be drawn in the picture, as a leaf node, with the value labelling the node.

This picture then is an RDF graph, and conveys much of the information of fig 2.

The (implicit) resource values of the properties are made explicit as unnamed circles, and the property names are used to appropriate link the ovals in the diagram.

This diagram does not suffer the problem of figure 2 that the labels GPS and IBM:GPS and NOKIA:GPS are used to show the relationship between the parent node and the labelled node, whereas the label "DPF Component" does not, which is visually confusing.

Response:

3rd June 2005: The DPF Group has reviewed the comment and Figure 2 has been updated to reflect A/B/C:GPS. This diagram is not intended to illustrate RDF graph structure.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
32FIs the order of children important( s4.2.7, HP, RDF comment r3 )

Our RDF graph differs from Figure 2 in that no ordering is given between the sibling IBM:GPS and NOKIA:GPS elements. This seems to us to be a better design.

Most of the time ordering is artifactual. e.g. an x,y coordinate pair <x>4</x> <y>5</y> describes the same point as <y>5</y> <x>4</x> since the ordinates are labelled.

Application code that relied on the x coordinate coming before the y coordinate, by for example, getting the first and the second children, rather than the x child and the y child, would, in our view, be broken. (e.g. it would not work if there was a new child labelling the point with a string given as the first sibling)

In the (relatively few) cases where ordering is important then making the tree deeper to express this seems appropriate. e.g. an rdf:Seq construct can be used, with properties rdf:_1 rdf:_2 rdf:_3 ... for the first, second, third values

Response:

Keith to replace 2.2 with explanation that properties are not ordered.

June 3rd 2005 Text response: Ordering is not important. Text has been added to Section 2 Point 6 as follows:The DPF component does not guarantee the order of properties. In addition, order of DPFPropertyList is not guaranteed either.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
33FTree or Graph?( General, HP, RDF comment r4 )

I am currently using a Microsoft Windows OS, it gives me a tree like view of my computer hardware, under the device manager. I can choose between two views of the devices Devices by type Devices by Connection

My understanding is that when I look at the properties of my DVD drive it is the same drive whether it's parent is a USB Mass Storage device whose parent is the USB Hub, or if its parent is DVD/CD-ROM drives whose parent is my computer.

So I am presented with two different trees whose leaf nodes are the same sets.

This seems to be a highly desirable feature if the goal is to allow different applications integrating devices from different manufacturers, since the different people involved with the development of the various applications and devices will have different views of the world. These different views will be reflected in different choices about how to structure their representation of the world, yet ... some of the concepts being used are the same and do represent the same devices.

We note that even in the more tightly controlled world of a Microsoft OS it is helpful to have multiple views.

In the XML world, it is natural to try to describe the world using tree like views. However, as RDF is a graph, it is possible to have a flexible representation where leaf nodes can be reached by multiple routes, accomodating different views of the world. Being able to accomodate such multiple views may be important as the goal here is to allow different applications integrating devices from different manufacturers. These different views will be reflected in different choices about how to structure their representation of the world, yet ... some of the concepts being used are the same and do represent the same devices.

RDF also stresses the idea that such representations should be designed from a semantic, rather than a syntatic viewpoint, and uses URIs to unambiguously identify subjects and properties. This approach should be used when designing representations in DPF.

Specifically DPF can gain some of these advantages if two small changes are made to DPFProperty: - permit multiple parents (not simply one or zero) - add a label, either a URI or a locally scoped identifier which identifies the instance which is the value of this property (when no literal value, string or other is given)

Response:

May 18th 2005 Text response: The DPF Working Group agree. The DPF is represented as a tree.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
34FInteroperability aspirations( General, HP, RDF comment r5 )

As far as we can tell, DPF does aspire to providing interoperability between devices and applications developed fairly independently rather than having a tight coupling between devices and applications.

However, no mechanism is provided for publishing the description of the properties supported by a particular device, or for publishing a description of the properties needed by a particular application. Without such mechanisms, functioning systems will require close cooperation between the device and application developement teams. There has been work both in CC/PP and within the OMA in UAProf on this problem, so there needs to be some coordination to ensure these approaches are compatible.

Response:

May 18th 2005 Text response: Publishing properties is considered beyond the scope of the DPF.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
35FProperty definitions etc.( General, HP, RDF comment r6 )

RDF Schema and the Web Ontology Language OWL provide mechanisms to define properties, including: - labels for the property in multiple language - giving the types of the subject and the object of the property - relationships such as subPropertyOf between this property and other properties.

The Device Independence Working Group have been work using OWL to describe properties. DPF collaboration and coordination should be explored with OWL and CPC.

Response:

June 3rd 2005 Text response: The DPF Working Group is exploring properties though DIWG work items in CPC. In addition the WD includes the text in the Introduction (Section 1.0).

The Dynamic Properties Framework is designed to provide direct access to properties even though they may be represented by particular vocabularies originating in different specifications and organizations. DPF concentrates on interfaces by which access to characteristics are obtained in programming environments, rather than on mechanisms used to represent the information. As a result, DPF provides a level of insulation from specific representations.

The DPF may well encompass ontology's for device properties and characteristics defined by other working bodies (for example [OMA]) and is therefore outside the scope of DPF. However, it is the intent of the Device Independence Working Group [DIWG] to specify representations of ontology's through [OWL], as well as presentation characteristics being developed by the [DIWG] through Core Presentation Characteristics [CPC] work item activities. Consequently, the DPF provides mechanisms to access device properties and characteristics whose ontology's and accessing interfaces are specified elsewhere.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
36FConstraining the use of properties to certain types( General, HP, RDF comment r7 )

(Open world/closed world issues)

A basic assumption in RDF and OWL is known as the open world assumption. This is that all descriptions are regarded as incomplete and extensible in any way not explicitly prohibited. One of the unfulfilled aspirations of DPF is for some sort of type constraints in the use of properties. While such constraints can be expressed in OWL it is quite difficult. An example of the difficulty can be given using RDFS (which is a subset of OWL). In RDFS it is possible to describe the domain of a property (i.e. the type of resources to which it is applicable) and the range of a property (i.e. the type of resource which may be the value of that property). However, a resource can have many types, so that having superficially conflicting domain and range rules does not actually cause a conflict, merely multiple typing. So if we had a property that was only applicable to nokia GPS's and (mis)used it on an ibm gps, we would (unfortunately) conclude that the ibm gps was also a nokia gps. This can be addressed in OWL by, in one way or another, saying that no resource is both an ibm gps and a nokia gps.

For an explanation of the often misunderstood relationship between RDF Schema, OWL, inference and validation please see http://esw.w3.org/mt/esw/archives/000048.html

Response:

May 18th 2005 text response: It is hard to understand precisely what issue is being addressed in this comment. The GPS example, with respect to Figure 2 has been updated to avoid explicit referencing to GPS and vendors. Furthermore, it appears to be about property name conflicts, that are not a problem for DPF. Suggesting that we are going to use OWL or RDF is incorrect. OWL and RDF are optional implementations for DPF.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
37FRelationship with Delivery Context( General, DIWG Comments )

DIWG believes that DPF should be viewed as a way of accessing any part of the delivery context. We consider that it might be necessary to access any characteristic of the delivery context while processing scripts, for example. Consequently we would like to see DPF described as such an interface within the DPF document, and would like to see the appropriate references made to DIWG documents. DIWG would be happy to assist in this work if deemed appropriate by the DPF editors and contributors.

Response:

At the f2f we agreed to sideline DIWG comments. In this context the CPC is relevant. However caution is required because CPC is not even in a public WD form. However, the DPF can be at candidate recommendation while the CPC is two steps behind.

Text has been added to the introduction as follows: The DPF may well encompass ontology's for device properties and characteristics defined by other working bodies (for example [OMA]) and is therefore outside the scope of DPF. However, it is the intent of the Device Independence Working Group [DIWG] to specify representations of ontology's through [OWL], as well as presentation characteristics through Core Presentation Characteristics [ref-CPC]. Consequently, the DPF provides mechanisms to access device properties and characteristics whose ontology's and accessing interfaces are specified elsewhere.

May 18th 2005: DPF WD has now included an Informative Reference to CPC (a current work item for the DIWG).

"Device Independance Working Group Charter, Work Item: Core Presentation Characterisitics Version 1.0", Rhys Lewis (Chair). (See http://www.w3.org/2004/05/di-charter-2004-06.html#delcon-cpc.).


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
38FData Model( General, DIWG Comments )

There is a danger that the DOM-based approach used in DPF could be seen as being in conflict with other specifications associated with delivery context. CC/PP, for example, uses an RDF-based representation. Unpublished work being carried out by DIWG into an ontology for device characteristics for use in delivery context is based on OWL. In fact, there is considerable agreement between DPF and DIWG on the need for path-based access.

DIWG has recognised the utility of path-based access to characteristics and of the potential for different uses to require different kinds of access. One consequence was the decision to use XPath expressions for access within its DISelect specification [4]. Although the starter set XPath functions defined in that specification directly imply the characteristics to which they apply, DIWG has recognised the need for path based access as well as full RDF Query-style access. This was part of the motivation for using XPath functions to separate the access from the underlying representation.

Consequently, the use of path-based access in DPF is completely consistent with the aspirations of DIWG. The challenge is to create appropriate ontologies that can be transformed into tree-based representations without ambiguity. DIWG's aspiration is to create a normative ontology for core characteristics that can be represented as a tree and that can also be extended with additional characteristics for use in different modalities and to represent additional aspects of the delivery context. The result should be the ability to specify essentially the same path in a DISelect element as is used in DPF to access the same characteristic.

Since this is the result of as-yet unpublished work, it is not surprising that there is no reference to this in the DPF document. DIWG would like to find a way in which the alignment of the path work in DIWG and the paths in DPF could be documented. DIWG also believes that specific characteristics arising from the multimodal use cases could be used to strengthen the ontology being developed within DIWG under the name Core Presentation Characteristics (CPC). Although DIWG is yet to publish a public working draft of this ontology, the requirements are available [5] and internal working drafts can be made available to the DPF team if that were to be felt appropriate.

Response:

May 17th 2005: There have been several discussions with the DIWG to resolve path-based access and an ontology representation of the properties. Text has been added to the WD Introduction as follows:

The Dynamic Properties Framework is designed to provide direct access to properties even though they may be represented by particular vocabularies originating in different specifications and organizations. DPF concentrates on interfaces by which access to characteristics are obtained in programming environments, rather than on mechanisms used to represent the information. As a result, DPF provides a level of insulation from specific representations.

The DPF may well encompass ontology's for device properties and characteristics defined by other working bodies (for example [OMA]) and is therefore outside the scope of DPF. However, it is the intent of the Device Independence Working Group [DIWG] to specify representations of ontology's through [OWL], as well as presentation characteristics through Core Presentation Characteristics [ref-CPC]. Consequently, the DPF provides mechanisms to access device properties and characteristics whose ontology's and accessing interfaces are specified elsewhere.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
39FAbstraction( General, DIWG Comments )

DIWG believes that there is considerable benefit to be gained by making access to characteristic values in DPF operate in a manner closer to that used in the XPath functions in DISelect. In particular, we think that it is necessary to protect the value of a property by use of access methods (or functions if you prefer), rather than allowing direct access to the data field. The major motivation relates to the issue of unit of measure, though additional benefits can accrue in terms of the data types returned by different calls.

Many device characteristics can be represented in a wide variety of units. Even the simplest linear measurements may use metric or imperial measures, for example. This is a challenge for a normative ontology. One approach is simply to define the unit of measure for each characteristic. The drawback is that for many basic measurements there is no obvious single candidate that will satisfy all constituencies. The approach adopted by DIWG for DISelect has been to support an appropriate set of units of measure for each characteristic. These are based on the sets of units supported within CSS [see 6 for example]. When making an access to the value of a characteristic, the caller supplies the unit of measure as one input parameter. The implementation returns the value in the requested units. This mechanism removes the burden of conversion from the caller while also removing the need for it to interpret the result to discover the units used. It has the additional benefit that it is possible to specify normatively the conversion rules to be used, when transforming values between representations, as part of the specification of the processor. DIWG is considering providing definitions of these conversion rules within its work on CPC. Such rules need to take account of conversion factors and appropriate accuracy. There has been recent discussion in DIWG on this topic (see for example http://lists.w3.org/Archives/Member/w3c-di-wg/2004Dec/0015.html and http://lists.w3.org/Archives/Member/w3c-di-wg/2004Dec/0012.html).

A useful additional benefit is that access functions for data fields could also perform the conversion to an appropriate data type. For example, it might be useful to be able to access the physical width of the display screen of a device in centimeters as a string, for use in presentation. Equally, it is likely to be useful to access it as a floating point number for use in comparisons.

In DPF, of course, the ability to modify characteristics means that some additional methods or functions are needed to allow the caller to specify the units in which the new value is being provided.

DIWG urges the DPF team to add the small number of functions needed to protect characteristic values and to enable proper support for units of measure. DIWG would be happy to assist the DPF team in this work if it were to be felt appropriate.

Response:

May 17th 2005: The DPF Group and DIWG are closely collaborating on CPC. Therefore this CR is considered complete.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
40FData Types( General, DIWG Comments )

Interfaces based around those designed for the DOM naturally use DOM-based data types. The normative vocabulary for Delivery Context will naturally use data types appropriate for OWL and RDF including, for example, those from XML Schema. Though these are clearly different, they are strongly related. DIWG would like to see an appropriate mapping developed and, since DPF already identifies a set of types, it might be appropriate to illustrate that in the DPF document. Again, DIWG would be happy to participate in this activity.

Response:

May 18th 2005: We are working closely with the DIWG. Specific reference to CPC. An Informative reference is as follows: "Device Independance Working Group Charter, Work Item: Core Presentation Characterisitics Version 1.0", Rhys Lewis (Chair). (See http://www.w3.org/2004/05/di-charter-2004-06.html#delcon-cpc.)


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
41FThe Live DPFPropertyList( s.4.3.1, DIWG Comments )

The description in 4.3.1 and 4.3.3 of the impacts on the property list of deletions is very implementation-oriented. This section would probably benefit from a slightly more abstract explanation.

Response:

May 18th 2005: We are working closely with the DIWG.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
42FProcessing Complexity( General, DIWG Comments )

As described, the model for determining values of characteristics appears to allow quite complex processing. For example, retrieval of some values might entail connecting to a remote service to retrieve a single value. It also seems to imply that a server might need to query the client for values that are only available there. It might need to do this multiple times in order to process a single request if several values were needed.

An alternative would be to make use of CC/PP profiles and differences. CC/PP was intended for this purpose. Where the level of dynamism is at the granularity of a request, this can be an appropriate mechanism. Where the level of granularity is finer, it may be that it is only appropriate for the processing that depends on the values to take place on the client.

Response:

18th May 2005: We are working closely with the DWG. On-going discussions with the DIWG indicate that CPC will be handle this interface to properties. The DPF provides a simple interface illustrating a layering of concerns, and that the implementation of the communication between client and server is hidden such that can be implemented in various ways depending on the needs.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
43FExamples( A2, DIWG Comments )

In the battery level example, it is worth noting that the DISelect elements are processed as the document is loaded. For this example, this seems to be an appropriate level of granularity. DIWG has not yet addressed the issues associated with reprocessing the DOM in direct response to events, but would be interested in doing so.

Response:

Agreed.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
44FStatic vs Dynamic( General, CSS WG via Bert Bos )

DPF allows a client to learn about a device's capabilities and configuration, which enables dynamic (on-the-fly) document generation suitable for a given media size; however, it does not provide for static generation of contents which present suitably on a variety of media sizes.

Response:

June 8 2005 text response: DPF covers static properties as well as dynamic. The Working Group believe this question refers to vocabularies that references the DIWG CPC work item. As a result, we have added the following text to the introduction: However, it is the intent of the Device Independence Working Group [DIWG] to specify representations of ontology's through [OWL], as well as presentation characteristics being developed by the [DIWG] through Core Presentation Characteristics [CPC] work item activities.

Informative Reference: CPC "Device Independance Working Group Charter, Work Item: Core Presentation Characterisitics Version 1.0", Rhys Lewis (Chair). (See http://www.w3.org/2004/05/di-charter-2004-06.html#delcon-cpc.)


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
45FSpecific Properties( General, CSS WG via Bert Bos )

While the infrastructure provided by this spec seems a good building block, additional standardization is required to specify the set of properties, attributes, events, etc. that are to be used in a specific solution; the protocol to be used for communicating these values must also be chosen. (An ECMAScript binding is provided as an appendix in the current proposal.)

Response:

June 7th 2005 text response: The DIWG CPC is expected to provide the answer for core properties and attributes.

June 22nd 2005 text response: The DPF WG has moved the ECMAScript bindings into a Normative section 7.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
46FImplementation investment and page size determinism( General, CSS WG via Bert Bos )

Implementation of this solution requires a discrete investment on the part of both UA's and clients which may be justified in some markets but will probably not be justifiable simply to provide page size determinism.

Response:

June 23rd 2005 text response:his could be implemented in numerous places and in the world of many different kinds of devices and dynamically changing context, allowing applications to be context aware, justifies the richer context. Sticking to smaller use-cases, clearly it is possible to operate without the DPF however, in other cases it is increasingly valuable.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
47FRelation to RDF properties( General, Dan Brickley )

The draft notes the link to CC/PP, which uses RDF, as well as a very broad scope for the kinds of properties that might be exposed via DPF.

Examples include device configuration, people descriptions / preferences, locations, environmental conditions such as temperature, battery levels, networking infrastructure (online/offline etc).

Since so many kinds of property could be useful within DPF, I believe it would be good to understand a few things about the potential relationship(s) between DPF's property model and RDF's. Both systems identify properties via namespace URIs and can be applied across a great number of descriptive domains.

Q: Can any/all/some RDF properties be used as DPF properties?

eg. wgs84:lat="30.12" for a location, or srw:masters="fr" to express competence with French. These are actual RDF vocabs btw, see http://f14web.com.ar/inkel/rdf/schemas/lang/index.en.html http://www.w3.org/2003/01/geo/

Response:

7th June 2005 text response: The DPF Working Group intends addressing the integration of RDF at some point. Howevver, it will not be detailed in this Working Draft because the DIWG is in the process of defining the CPC work items (link below).

http://www.w3.org/2004/05/di-charter-2004-06.html#delcon-cpc


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
48FAre there any RDF properties which cannot be used as DPF properties?( s3, Dan Brickley )

(http://www.w3.org/TR/2004/WD-DPF-20041122/#s3 suggests that this might be the case, since RDF properties can lack datatype restrictions, and don't use the DOM approach adopted in DPF, but instead allow XML schema-style datatyping via a datatype URI).

Response:

15th june 2005 text response: Yes. Any properties that do not conform to the RDF usage patterns for delivery context would not be accessible in DPF.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
49FCan any/all/some DPF properties be used as RDF properties?( General, Dan Brickley )

If so, please consider adding an appendix specifying the exact RDF triples that correspond to a DPF property, or larger property tree. Detail will likely be needed regarding datatype URIs for literal-valued properties, and perhaps some consideration for reflecting resource URIs into the RDF graph (eg. via well known DPF properties whose values are URIs? <- thinking out loud).

Response:

15th June 2005 text response: No. All properties accessible in DPF are representable in an appropriate form of RDF.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
50FAre there any DPF properties which cannot be used as RDF properties?( General, Dan Brickley )

(this affects, for example, our ability to use the upcoming RDF Data Access WG's SPARQL query language for matching against DPF-modelled data alongside CC/PP, UAProf and other RDF data, eg. describing locations, natural language prefs etc.).

Response:

15th June 2005 text response: No. All properties accessible in DPF are representable in an appropriate form of RDF.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
51FCardinality and property( s4.2.7, Dan Brickley )

Can the exact same property (eg. 'net:hostname') be applied to a single DPF-described entity directly? The spec gives the impression that this isn't allowed (presumably simplifying the edit/update APIs), and that nested structures, or a NodeList, have to be used rather than simple property repetition. Or am I misreading? (quite possible...)

Response:

16th June 2005 text response: The DPF Working Group does not understand the comment. Further clarification is required.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
52FProperty Declarations( A2, Dan Brickley )

...how do DPF adopters publish and publicise their DPF property namespaces? Do you have an mechanism/plans/roadmap to allow properties to be documented in some form other than human-oriented prose? eg. from B1: DPF.location.format="postal code";

Who defines the property 'location'? In practice, what do they do to tell users of the property that it's correct value is an entity that has properties such as 'format'. I assume some namespace mechanism disambiguates 'location' and 'format' by associating them with URIs, but am unclear how this alone is enough to support the loosly-coupled, multi-party heterogenous extensibility that DPF seems to aim for.

If I'm a DPF adopter and want to publicise a property that applies to locations, and I've somehow found the URI for this 'location' property, what do I do? Pretend my new property is danbri:averageRainfall, and I've a domain name etc etc I can assign to it. What can I do, in a machine-readable (and hence more I18N-friendly than prose) way to say that my danbri:averageRainfall property is intended to apply to the kind of thing that b1:location takes as its value? How do we help DPF adopters, many of whom won't read English, from mis-using the 'location' property, eg. by using it with textual strings values. Can XML schema languages be used somehow? RDF/RDFS/OWL? Is new work planned in this area?

This is related to my questions above of course, since RDF/RDFS/OWL might serve as an already-existing property declaration mechanism, assuming the datamodels match up. But it could well be the case that RDF doesn't suit your WG's needs, or even that figuring out whether it is usable could be too expensive an undertaking. I intend the questions above as small steps towards figuring out how DPF and RDF might inter-relate, rather than as evangelism/advocacy to persuade you all to "go over to RDF"!

So I should stress that while I'm clearly coming at this problem space from the RDF tradition, I don't yet know enough about DPF. These are my initial reactions on reading the WD, basically that it would be good to be able to consume DPF data in RDF environments, since RDF is also based around a hetergenous model for properties. And also that there are many RDF-defined properties already in existence, some of which might address DPF usage scenarios. I'd like to be able to advice RDF and DPF adopters on whether a single property URI/namespace can be used, and if not, have some explanation to offer them to account for apparent duplication.

Response:

16th June 2005 text response: DPF does not of itself define any vocabularies. It relies on other specifications, such as CC/PP, UAProf and CPC to provide appropriate vocabularies


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes
53FDefining event types in terms of DPF-based expressions?( General, Dan Brickley )

"For each property, information may be provided for use in initialization, and for determining the conditions under which events are raised to signal updates to the property value."

This gave me the impression that I could use conditional expressions such as those in Appendix B, to define event triggering conditions (perhaps conceived of as defining event types).

The expression used in Appendix B2 interacts with the HTML via the DISelect spec. Could the expression instead be associated with a type of event, so that scripting in the style of B1 would be possible.

eg. "dpf:component()/device/battery < 20" ...as a trigger condition to raise a LowBatteryConditionEvent.

Is this possible? planned? or a misunderstanding of your approach?

Response:

16th June 2005 text response: No, there is no intent to support conditional event triggering in this version of the specification. We have updated the XPath example to try and clarify the meaning.


Approval:
Keith Waters: Yes, Dave Raggett: Yes, Sailesh Sathish: Yes, Rafah Hosn: Yes, Matt Womer: Yes, All: Yes