Structures Editor's Draft

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Structures Editor's Draft

JOSE MANUEL CANTERA FONSECA

structures.html (34K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Structures Editor's Draft

Andrea Trasatti-2

Hi José,
thank you for the reference to me in the document. My last name is  
"Trasatti", of course, 1 s, 2 t's. :)

Chapter 3.1 says that the user should pass the XML to the API. There  
is no definition of how to do that. Also, why limit to only 1 file? I  
imagine developers defining different grouping rules in separate  
files and then using some of the rules at run-time depending on the  
local needs. An array should be supported.

I see that you defined the possibility to specify the aspect, but  
wouldn't this be a required parameter when defining the groups?

Group ID's should be unique, I don't think you specified it in the  
document.
Group ID's seem to be case sensitive from the way you built your  
examples.

- Andrea


Il giorno 19/giu/08, alle ore 14:48, JOSE MANUEL CANTERA FONSECA ha  
scritto:

> <structures.html>


Reply | Threaded
Open this post in threaded view
|

RE: Structures Editor's Draft

Rotan Hanrahan

For the benefit of others interested in this work, please note that we plan at this stage to publish this as a WG draft, but evolution of this work will be directed to elsewhere within W3C.

Merging of XML files into a single representation is a well-understood mechanism. A future update of this work might consider documenting such merger, and/or provide other means for processing multiple inputs.

In the DDR Simple API, when an aspect is expected but not given, then the "null" aspect is assumed. This provides support for vocabularies based on representations where support for aspects had not been anticipated. I assume that in the case of Structures, the optional nature of aspects is for the same reasons, and is handled in the same manner.

Uniqueness of IDs is important, yes. The scope of the uniqueness is something that should be considered in future.

The case-sensitivity should be documented to avoid misunderstanding. In general, IDs represented as Strings should be taken as literals, such that case is significant. Apart from efficiency, it avoids certain locale/culture issues where case mapping is not so simple. (Consider the Turkish language, for example.)

---Rotan

PS We generally don't modify the content of attachments, even if there's a typo in someone's name, but rest assured that we will verify spellings when we give this document a more permanent location.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Andrea Trasatti
Sent: 21 June 2008 08:11
To: JOSE MANUEL CANTERA FONSECA
Cc: [hidden email]
Subject: Re: Structures Editor's Draft


Hi José,
thank you for the reference to me in the document. My last name is  
"Trasatti", of course, 1 s, 2 t's. :)

Chapter 3.1 says that the user should pass the XML to the API. There  
is no definition of how to do that. Also, why limit to only 1 file? I  
imagine developers defining different grouping rules in separate  
files and then using some of the rules at run-time depending on the  
local needs. An array should be supported.

I see that you defined the possibility to specify the aspect, but  
wouldn't this be a required parameter when defining the groups?

Group ID's should be unique, I don't think you specified it in the  
document.
Group ID's seem to be case sensitive from the way you built your  
examples.

- Andrea


Il giorno 19/giu/08, alle ore 14:48, JOSE MANUEL CANTERA FONSECA ha  
scritto:

> <structures.html>