This document summarises the comments received following the publication of the second Last Call Working Draft of the DCI specification. The dispositions of comments from the first LCWD were compiled previously. Note: responses to comments were not formally sent but corresponding changes were made to the second Last Call draft. The second Last Call period was a review of the whole document and not only the differences with the first LCWD.
Original: http://lists.w3.org/Archives/Public/www-di/2005Dec/0000.html
Response: http://lists.w3.org/Archives/Public/www-di/2006Jan/0001.html
Acknowledgement: http://lists.w3.org/Archives/Public/www-di/2006Mar/0000
Status: Resolved
Nilsson 1:
DCI specifies a general framework for HTML pages to access device properties. However, the tangible set of device properties to access is not included in the DCI specification. Which are the plans for the definition of these properties? Do you have any cooperation with other W3C groups or with other standardization organizations? Alternatives are for example to look at the OMA UAProf properties or to start out from the JSR APIs and to create ECMAscript bindings.
Response:
In the introduction (http://www.w3.org/TR/DPF/#sec- introduction) we do state that "the Delivery Context Interfaces are designed to allow for properties to be defined by different organizations. For instance, the W3C Device Independence Activity [DevInd] is working on defining a set of core presentation attributes. The Open Mobile Alliance [OMA] (formerly known as the WAP Forum) has developed a set of properties for describing static characteristics of mobile phones. Device vendors are expected to define additional properties for proprietary features."
Nilsson 2:
In appendix B there are two informative use cases for DCI. However, we would like to see more tangible use cases in order to achieve a better understanding of the motivation for DCI and what it can be used for.Response:
Agreed. There are no more examples in spec, but as implementations are created examples may well be published in a separate document.
Nilsson 3:
Security is important. Values can be set by scripts and there must be functionality for access control. Should there functionality to distinguish between any 3rd party web site and "safe" sites? Should there be a separation of "safe" properties that can be accessed by any site and "sensitive" properties that can be accessed only by "safe" sites.
Response:
We will update the draft to (section 8.1) to provide a listing of exceptions that would be raised during security and access right violations. It is up to the implementation to raise those events under the appropriate conditions for the appropriate properties.
Nilsson 4:
The interpretation of the acronym DCI is inconsistent. At some places in the specification it is said to mean "Device Context Interfaces" and at other places it is said to mean "Delivery Context Interfaces".
Response: Thanks! We will do the necessary editorialization.
Nilsson 5:
For your information: Within the OMA BAC-UAProf working group there is an activity called "Device Profiles Evolution" (DPE) that aims a defining an enhanced device profiles mechanism which allows a device to convey the dynamic capabilities to a service provider in real time, thereby ensuring that the service provider can provide content best suited to the capabilities of the device at that time. As this activity deals with the problems of addressing dynamic changes of device characteristics there may be connection points between the work with W3C DCI and OMA DPE.
Response:
Thank you for the update, we are aware of OMA and are working with them.
Original: http://lists.w3.org/Archives/Public/www-di/2005Dec/0002.html
Response: http://lists.w3.org/Archives/Public/www-di/2006Jan/0000.html
Acknowledgement: http://lists.w3.org/Archives/Public/www-di/2006Oct/0005.html
Status: Closed.
Dahl 1:
We notice from section 4.1.2 that DCI access to remote device properties is supported. Consider the case where multiple devices are cooperating in a single application. If one of the devices wants to monitor properties on all the others, will it have a single instance of the DCI, with a separate branch for each device, or will it have multiple instances of the DCI? From section 4.1.6, it would appear that the former would be the case, but we would like this to be made explicit.
Response:
the DCI specification does not confine developers as to how many instances of the DCI tree they can/should have or who should host these instances as these are implementation dependent. One possible implementation in a multimodal framework is to have one instance of the DCI tree hosted by the interaction manager and have appropriate remote access mechanisms for remote devices that need to update/montior properties in that tree.
Dahl 2:
Secondly, do questions of efficiency arise with remote devices? The obvious way to implement a remote DCI interface is to maintain a local copy which would be updated via update events.
Response:
we acknowledge the need for protocols and access methods for remote properties however we believe that this is out of scope, at least for the first release of the DCI specification.
Dahl 3:
Could there be cases where the remote DCI interface needed less frequent updates than one local on the device? There will be implementation-specific ways of handling this, but is a more general means needed?
Response:
again, we do acknowledge the need for efficiency mechanisms (as mentioned in section 4.1.4) specially to alleviate the number of events fired, for example, when a property gets updated very frequently and an application only requires notification at certain intervals. We have decided to leave this out of this release and have implementors decide how best to optimize property updates and access.
Acknowledgement:
http://lists.w3.org/Archives/Public/www-di/2006Oct/0005.html
Thank you and the Device Indepence Working Group for considering the comments from the Multimodal Interaction Working Group [1] regarding the DCI second Last Call Working Draft. The MMI Working Group has discussed your comments and we are satisfied with your responses. However, in reference to point 2, we would like to encourage you to consider remote access in more detail in future versions of the DCI specification. [1] http://lists.w3.org/Archives/Public/www-di/2005Dec/0002.html
Original: http://lists.w3.org/Archives/Public/www-di/2005Nov/0001.html
Response: http://lists.w3.org/Archives/Public/www-di/2006Jun/0002.html
Acknowledgement: none received
Status: Not Acknowledged.
Baron 1:
I notice that the DCIProperty interface defined in [1] uses multiple inheritance.
None of the DOM WG specs use multiple inheritance of interfaces because, as I understand it, the DOM WG decided that avoiding multiple inheritance was a valuable invariant to maintain. Invariants, including this one, are useful in keeping implementations simple. This break with the convention can also make your interface impossible to implement correctly in some bindings, such as those that depend on COM or XPCOM, which was probably an important use case when the DOM WG decided not to use multiple inheritance of interfaces. (Those bindings, in turn, may rely on single inheritance to simplify function calls between languages.)
Working groups should not break the invariants established by other groups: doing so leads the Web down a path towards higher implementation complexity and thus lower reliability. It also often leads to the worst of both worlds (many interfaces give up the advantages of multiple inheritance, while implementations still have to deal with the extra complexity for the handful that broke the rules).
Response:
Thank you for your comments. As per your request we have changed the IDL and all references to remove multiple inheritance from the interfaces, while adding text to indicate that when implementing DCI, they should inherit from both Node and EventTarget.
Original: http://lists.w3.org/Archives/Public/www-di/2006Sep/0000.html
Response: http://lists.w3.org/Archives/Public/www-di/2006Sep/0001.html
Acknowledgement:None
Status: Not Acknowledged.
- Why have the nodeValue be the string "NULL" and not simply have the null value as is usually the case for Nodes that don't have a value? This breaks some assumptions that implementations can make and might increase footprint for no obvious (from reading the draft) gain.
Response: yes, this is an error and it has been corrected
- The valueType attribute is open-ended in what it can contain but you don't describe how vendors should name their types, which in turn may lead to type name clashes. You should probably recommend that vendors name their extensions using IRIs (this doesn't mean you have to use IRIs yourselves, you can claim that you are the only source allowed to use plain strings).
Response: We recognize the need to for metadata ontology's and datatyping and the DIWG will cover this in detail in a future specification. In addition, Section 5.1.1 the text has been modified as follows:
To avoid name clashes the values for valueType should be a URI.
Also, why is this NULL (or null) for DCIComponents?
Response: DCIComponent doesn't have any of these and hence they are NULL.
- Same comments for propertyType and DCIMetaDataInterfaceType (for the latter, unless it is always a media type, in which case this should be specified).
Response: this cannot be done because DCI implementation cannot know what the metadata structure is.
- While the "any" type *might* make sense for a value since it could be a simple value (e.g. an int) just as well as an object, is that the case for DCIMetaDataInterface? Wouldn't it always something more structured than a simple value, say at least a string?
Response: This cannot be done because DCI implementation cannot know what the metadata structure is.
- *Please* don't use null to indicate a wildcard for namespaceURI
or propertyName. This is different from the way the DOM does it, and
can cause confusion as to what describes properties in no namespace.
Use the star instead ('*') as the other specificiations do.
Response: comment accepted and error corrected.
- Is there really a need to have both searchProperty and hasProperty when they are so close? Experience shows that as soon as you add a convenience method to an API, users will clamour for a zillion others such as searchForDogFoodProperty and getAnArmForAHandProperty. If convenience methods are needed, they are best introduced in a second version based on experience from what users find difficult to do (or what is inefficient to implement), as for instance DOM 3's textContent.
Response: The feeling in the group is that there is sufficient difference between the methods. The main reason is that hasProperty can terminate as soon as the first match is found. Search has to continue to find all possible occurrences. In addition there are use cases where knowing that a property exists is sufficient and the exhaustive search can be avoided.
- There is confusion regarding what exceptions are to be raised, DOMException or DCIException. You can't reuse DOMException to add your own exception codes because that is highly likely to clash with future extensions to the DOM, therefore DOMExceptions must only be raised when an existing exception as specified in the DOM is raised, for all other uses a DCIException (which could wrap a DOMException) has to be used. It's unclear from the draft which is which. The IDL only ever mentions DOMException with values it doesn't have (and using the strange "raises(DOMException::FOO_ERR)" instead of just "raises(DOMException)" with the prose saying which codes may apply) and doesn't define DCIException (!) while other parts talk of DCIException. Please change the draft to define the latter and to use it when DOMExceptions don't apply.
Response: comment accepted. The specification has been amended so that a DCIException is defined and used by other methods.
- I have trouble understanding the relationship between a DCI DOM tree and a DOM tree representing an XML document. You extend Node directly, thereby creating new node types (which is a major issue, as future versions of the DOM itself may themselves need to add node types, in which case you would be clashing with them -- this is *not* a theoretical problem, you are already clashing with DOM 3 XPath) but you don't clearly define the behaviour of these nodes when other DOM operations are applied to them. What happens if someone tries to serialise that DOM? What are the nodeName, baseURI, attributes, childNodes, first/lastChild, next/previousSibling, ownerDocument, prefix, or textContent set to for DCI nodes? What happens if I try to append a DCI node as the child of an element or attribute node in the DOM, or vice-versa? What happens when I call cloneNode, compareDocumentPosition, getFeature, getUserData, isEqualNode, lookupPrefix, etc. on them? The DOM defines this for the types which inherit from Node, but you don't, which potentially opens the door to interoperability issues as much is left to implementations. I would recommend either a) clarifying the relationship to the DOM (which may constitute major work and is an error-prone process), b) removing the inheritance from Node (this requires checking that events would still work, but so long as you inherit from EventTarget I think you're fine), or c) defining the DCI tree as a tree of elements (which may never be serialised as XML), and therefore inheriting from Element (this has the advantage that they can be dumped as XML easily, but may have issues in that you would have to specify what happens if a DCI element is imported into another document). I think that option (b) is likely to be the one that will remove the largest set of issues with minimal work, especially since you don't seem to be making much use of the fact that you inherit from Node, apart from reusing a few fields.
Response:
The DCI group see inheriting from the DOM to be the correct and valid approach for DCI. In particular we recongize the need to re-use the DOM to simplify the DCI implementations through the inheritance of the DOM node. As a result, the DCI interfaces are designed with the DOM as a key component and the DOM-tree structure to be familiar, minimal and re-usable for implementors.
To clarify we have added the following to the doc in Section 4.1:Unless specifically stated otherwise the behaviour of DCI is the same as DOM.
In Section 7 (after the list of exceptions)The following text has been added to the doc:Importing, adopting and cloning DCI nodes is platform dependent and in general, authors should be careful when using these methods on a DCI property tree.
The degree of support for cloning, import and adopt methods on DCI nodes is vendor specific. If these methods are not supported implementations must raise the DOM exception 'NOT_SUPPORTED_ERROR'.
For behavior variance with DOM, please see section 7 Conformance where DCI behavior conflicts with that of DOM is specified. In all other cases, the DCI tree behave the same way as mentioned in DOM specification (mentioned in DCI specification - section 7).
Load and save is out of scope for this version of DCI. We anticipate addressing this topic in future DIWG work items.
We have added to the assumptions in Section 2: DCI represents the delivery context. The delivery context is separate from the document markup. The document originates with an author. The delivery context originates with the device, the network etc. DCI nodes are not intended to appear within document markup.
There is a relationship between markup documents and the delivery context. We will investigate this further in the context of DCI in future work.
- Section 2 point 5 has "To be discussed 16th Sept f2f". I assume you don't want that in your CR document :)
Response: corrected.
- Section 3 is a bit wooly, using terminology like "this will build upon the types defined by the W3C DOM working group" (is it not done already?) or "some of the common data types in the DOM include" (is the list exhaustive or not?). It would be best to make the list exhaustive so that implementers immediately know what they need to reuse from the DOM, even if the definitions for the types are left to another specification.
Response: Agreed. The list has been made exhaustive and the conformance section makes clearer the normative dependency to the DOM.
- You define DOMString as "a Unicode string encoded with UTF-16". I would drop the "encoded with UTF-16" since while that's pretty much what the DOM and the IDL prescribe, it is something that language specific bindings typically override as an implementation detail (many languages map DOMString to their native string constructs, which are often in UTF-8 internally, even though they can always produce UTF-16 on request).
Response: document corrected.
- This is unclear: "the DOM NodeList interface when used within the DCI context would return a DCIProperty instead of a DOM Node". I suppose that you mean that NodeList::item() returns a DCIProperty instead of a Node? That's somewhat wrong as in most languages that enforce some notion of typing it won't be possible to have that method return a type instead of another. I think you'd be better off saying that NodeList::item() must return Nodes that can be casted to DCIProperties, or something along those lines. Also, wherever that's the case it needs to be specified normatively (i.e. not in a sentence that starts with "for example").
Response: Agreed. The new sentence would be "Within the DCI context, the DOM Node that is returned through the DOM NodeList::item() method call should be interpreted as a DCIProperty". As for the example statement, we prefer to leave it as it is since the preceding statement clearly mandates viewing all DOM calls within DCI context. The sentence, even though normative by nature, is meant to highlight one of the many scenarios that could occur when using DOM calls within DCI context.
- Unclear as well (in 4.1): "This is independent of the event propagation model in the host environment." I think you mean that if the host environment dispatches events through carrier pigeons and therefore only supports the "flying/cooing event propagation model" it still needs to support bubble/capture for DCI, but it could be expressed more clearly. Also, have you considered making the capture phase optional? Some other DOMs already do that (for instance the SVG MicroDOM). The capture phase adds implementation overhead for no obvious value (IMHO).
Response: What is meant through that sentence is that DCI has an independent event system that is not tied to the host platform i.e a the DOM document (xHTML for instance) would have its own event propagation system that is independent of DCI eventing. The DCI eventing is taken care of by the DCI platform.
Capture allows a listener to listen for property change events before the event hits the target node. If there are any problems with that then we can make it optional, but I don't see why we need to special case it if we have no problems. The more compliant we are the the DOM event propagation algorithm the better it is.
- You consistently use the word "metadata" (which seems fine to me) yet you called the corresponding interface "DCIMetaDataInterface", capitalising the 'D' which suggests that it's really "DCI Meta Data Interface". CamelCase is already somewhat hard to guess, especially for non native speakers, so being consistent and calling it "DCIMetadataInterface" is probably best.
Response: aggreed. document corrected.
- In some places you state that some attributes need to have the
value NULL, where it's unclear whether that's the string "NULL" (as
for nodeValue) or the null value. If the former then please consider
using the latter instead, and if the latter then the normal way of
flagging it in W3C specifications is to use null
(lowercase).
Response: aggreed. document corrected.
- 5.1.2.1 "This method is used to determine whether this property has a given named property". I find this quite hard to parse, maybe you should tag "in its descendants" at the end?
Response: aggreed. document corrected.
- In 5.3, you seem to indicate that the version is a string that has to be "1.0" (for this version), entailing that "1", "1.0.0", etc. are invalid and compare differently. Experience shows that if you don't state this in excruciating detail people *will* get it wrong and perform numeric comparisons.
Response: aggreed. document corrected.
- In B.2 you use the text/javascript media type which is deprecated in favour of application/ecmascript. Also, there is no NULL object, just null (though since it hasn't been declared it'll resolve to null, but it's still bad practice). If the document intends to be XHTML (which it looks to be from the XMLDecl and the namespace) then it MUST include the relevant DOCTYPE (yes I know that's terrible, but complain to the HTML WG :). The second script element seems to add a listener to the head element, it's unclear to me that this element ever sees that event.
Response:
- The ob-RFC2119 reference "In this document the key words must..." is placed in the introduction, which I assume to be informative. It might be best to place it in the conformance chapter. - You mention "cell phones", AFAIK this is an americanism to which the more generic "mobile phone" (or device) is generally preferred. - You talk of "URIs". The terminology this week is "IRIs". - When including a diagram, it's nice to also provide an SVG version. - "a NodeList with length attribute value of Zero": no need to capitalise Zero. - "If the return value is true, the node is included otherwise, the node is rejected" should be "If the return value is true the node is included, otherwise it is rejected."
Response:
- Do you plan on defining a metadata interface more completely in the future, or is that completely left up to other specifications?
Response: defining a metadata interface is outside DCI scope, we expect some other specification, or vendors to publish their metadata structures.
- It seems to me that using the IDL "any" type may cause compatibility issues with some languages, do you have a rationale for not using DOMObject there?
Response: we use "any" because DOMObject is only available in DOM Level 3. Therefore we kept "any", which we mapped to String or DOMObject, for DOM level 2 and 3 respectively.
Original email: http://lists.w3.org/Archives/Public/www-di/2006May/0011.html
Response: http://lists.w3.org/Archives/Public/www-di/2006Sep/0002.html
Status: Not Acknowledged.
Many of the comments in that email are editiorial in nature and have led to an immediate correction. No response from the Group to the commenter is deemed necessary, other that this statement.
2 Assumptions 6. The DCI framework does not specify a required DOM level. But in the Conformance section it implies that at least DOM Level 2 is required, so perhaps this assumption is false.
WG response: will change text so that at least DOM Level 2 is required.
3 Datatypes for PropertyValues
This will build upon the types defined by the W3C DOM working group.
[...] Some of the common data types in the DOM include:
* boolean: for values that are either true or false
Note that while the other other types in the list are, 'boolean' is not
defined by the DOM IDL and is actually a core part of the OMG IDL.
WG response: the goal is actually to list all the types in the spec's IDL,
not just the DOM. So we've clarified by removing 'in the DOM' in: "Some of
the common data types in the DOM include...", and we actually added the
any type.
The DOM normally handles errors by passing back error conditions. In some circumstances, a DOMException may be raised, [...] Does "passing back error conditions" mean returning error values from function calls? If so, then DOMExceptions seem to be the actual normal way of signifying errors in DOM.
WG response: we have changer our wording to just "The DOM normally handles errors by raising exceptions, for example when a read-only property is modified."
4.1.1 Initialization of Properties It's not defined what initialization and de-initialization of properties actually means. Does it mean added/removed from the tree? Or does it mean set to have some value/set to have an undefined value?
WG response: No change. The DCI framework doesn't impose a particular initialization mechanism for setting values on properties and/or attaching a property with a default value onto the DCI tree. Both of these mechanism are left to the providers because they are property specific.
4.1.6 Property Layout DCI places no restrictions on names or namespace attributes that properties contain. So the namespaces of properties need not even be syntactically valid URIs? While in section 3 it says that "XML namespaces and URIs in general are treated as being of type DOMString", it does not specifially say that names must be DOMStrings (although one can infer it from the methods in the IDLs that take 'DOMString propertyName' arguments).
WG response: we added a sentence saying that property names must conform to XML names, and URI names must be valid per RFC2396.
Also properties can be placed anywhere within the DCI hierarchy (however it is recommended that they follow logical rules that are outside the scope of DCI). I don't know what it means to recommend that properties be organised according to rules that are not defined.
The sentence (in parenthesis) is a suggestion to use sensible principles, rather than specific rules. DCI is not recommending any normative guidelines for property hierarchy layout. New text (in parenthesis): the rules for hierarchical property layout are out of scope for DCI.
I realise that the example used in this section is meant to demonstrate how to disambiguate queries that return multiple nodes, but I wonder about the actual use of a query where the namespace URI is set to "*". Surely only the combination of a namespace URI and a property name gives meaning to the property node--after all, B:GPS may be a Gadget Perhiperal Status property, something unrelated to global positioning system devices. I guess my concern is that the query presented isn't a realistic one.
We understand that the query example is somewhat obscure and unrealistic. However the intent is to illustrate how to disambiguate the same name and namespace values, when they appear to be identical by comparing parent nodes. In addition, as we move to candidate recommendation, we expect to provide (in a separate document) more typical examples of DCI usage.
5.1.1 Attributes In DCI context, the DOM Node nodeValue attribute should be the string NULL. Is it really the string "NULL", or should it be the null value (or perhaps even an empty string)?
WG response: editorial error, text corrected.
The readOnly attribute is used to determine whether the value attribute can be modified. When readOnly is true, any attempt to modify the value attribute will result in an exception being raised. When readOnly is set to false the value attribute may be changed. This attribute indicates whether 'value' may be changed, but maybe it should also indicate whether 'propertyType' may be changed, too, since changing 'propertyType' will likely result in a different interpretation of the property.
WG response: agreed. Changed the specification to say that changing the propertyType attribute will raise an exception if readOnly is set to true.
The DCIProperty interface description does not say how a property's namespace URI and name can be accessed. Are these meant to be accessed from the Node interface's namespaceURI/nodeName/localName attributes?
WG response: yes. We clarified the text by reminding that "These methods are defined in addition to the standard DOM interface methods."
5.2 The DCIPropertyFilter Interface The IDL doesn't say that acceptProperty raises a DCIException, but the Exceptions section of the prose says that one of type PROPERTY_FILTER_ERR is raised. Is this exception inteded to be raised by authors in their implementation of acceptProperty? If not, I think this exception should not be listed here, as it is actually DCIProperty.searchProperty that raises it.
WG response: the exception is indeed expected to be possibly raised within acceptProperty. We corrected the incorrect function definition.
5.3 The DCIComponent Interface The parent attribute of an DCIComponent has the value NULL. Should this be the 'parentNode' attribute?
WG response: yes. Typo fixed.
The following events are of particular interests to DCI listeners: Is that any indication of what events are dispatched? For example, are the DOMNodeRemovedFromDocument and DOMNodeInsertedIntoDocument ever fired?
WG response: the only event that DCI framework specifies is the dci-prop-change event. However, since the DCI tree is a DOM tree, then the other events stated will be fired. The spec suggests (but does not mandate) some of the events that might be of interest to DCI users, such as DOMNodeRemover.
I suggest that these DOM Events defined event types are included here just by reference, rather than providing a duplicate description of these events.
WG response: We are just mentioning some of the events that might be of interest to the DCI spec readers, as means of guidance, with the full awareness that users will indeed follow up with the actual DOM events. And we have added a direct link to the DOM spec.
7 Conformance
Although, the DCIProperty interface inherits from the DOM Node
interface, not all of the attributes and methods defined for the Node
interface are applicable to delivery context properties. In particular
implementations:
[...]
What must happen for attributes and operations on the Node interface
that aren't listed here, such as cloneNode and textContent? Are they
implementation defined?
WG response: thank you, this was a good catch. We've added the requirement
for the textContent attribute to be null if DOM Level 3 is
supported. However, the methods specified in the DOM Node IDL are applicable
to a DOM DCI tree, subject to security and access policies that are defined
outside DCI scope and may be implementation specific.
Note: The DOM 3 Event Note adds the notions of event namespace, groups and categories to the DOM 2 Event Recommendation; these are useful features in the DCI context. DOM Level 3 Events has recently been returned to Working Draft status, and event groups are at risk of being removed due to lack of use cases. If these indeed are useful for DCI, you should consider notifying the Web API WG.
WG response: thanks, we are following up with the Web API WG.
B.2 GPS Resolved Postal Code With this line: var location = childProperty(DCI, "location"); Does this imply that a "DCI" property on the ECMAScript global object is the intended method to expose DCI information to script? Should this be specified in the ECMAScript binding section? And for these lines: format.nodeValue ="postal code"; [...] updateDistance.nodeValue = "50m"; [...] field.firstChild.nodeValue = location.nodeValue; shouldn't these references to nodeValue actually be propertyValue (except for the field.firstChild.nodeValue, obviously)?
WG response: regarding the first comment, access to the DCI object is implementation specific. For example, some browsers can offer DCI as a global object or provide handle to DCI tree through the getFeature call in DOM. Regarding the references to nodeValue, we have corrected these errors.
B.3 Battery Level The comment about "dcn:getPropertyValue" in the code doesn't seem to be relevant, given that dcn:search is the XPath function used in the sel:expr attribute. This example also doesn't seem to exemplify the interfaces defined by this document.
WG response: agreed. We have removed the example. Although it seemed interesting to show DCI used in contexts other than scripts, the interface with DISelect access functions isn't specified yet, and we don't want to confuse readers by making something up which might be wrong later.