One Last Batch of Technical Queries
Hi everyone! We (Ali, Darren, Andreas and myself) have almost finished the final editoral actions to make the spec ready for public consumption, but a few minor issues remain. (My opinions on each are in parentheses.) Processor Architectures (Table 4-2 in 4.2.2.1) Should 'x86' really be called 'ia32'? (I don't really care.) Resources Element Definition (5.4.1.1) Do we need to say anything about what it means to satisfy the whole set of elements? (I think we just need to say that the Resources element is satisfied when all of its contained resource requirements are satisfied.) Do we need to say anything about what happens when you have both Total and Individual elements? (I think not...) Source and Target Element Pseudo-Schemas (5.5.6.5 and 5.5.8.5) Should the multiplicity of URI be "1" or "0-1"? Conceivably, people might want to stage to things expressed (using extensibility) as things other than URIs. (I'm inclined to say 0-1, but consistency between spec and schema is much more important.) The plan is to have a full finished version of the spec (to be revision 20) by the end-of-business on Monday, so any responses to the above points must be done *promptly*. Donal.
Hi, first, thanks for the "dirty work" to all of the editors. Next, my comments on the last issues inlined below: On 3 Jun 2005, at 11:22, Donal K. Fellows wrote:
Processor Architectures (Table 4-2 in 4.2.2.1) Should 'x86' really be called 'ia32'? (I don't really care.)
'x86' is no doubt the more common term - to be honest, only a small faint bell is ringing for ia32, and I am really not sure if this term really exists. All tools, programs and descriptions I know (i.e. the GNU tools collection) do all use x86 and ia64 to separate 32 bit and 64 bit architectures.
Resources Element Definition (5.4.1.1) Do we need to say anything about what it means to satisfy the whole set of elements? (I think we just need to say that the Resources element is satisfied when all of its contained resource requirements are satisfied.)
Yes, I would support this logical AND semantics.
Do we need to say anything about what happens when you have both Total and Individual elements? (I think not...)
Well, both have to be satisfied, otherwise the whole Resources element will not be satisfied. So I'd recommend mentioning this.
Source and Target Element Pseudo-Schemas (5.5.6.5 and 5.5.8.5) Should the multiplicity of URI be "1" or "0-1"? Conceivably, people might want to stage to things expressed (using extensibility) as things other than URIs. (I'm inclined to say 0-1, but consistency between spec and schema is much more important.)
I think it should be "1". Although the "U" in URI stands for "Uniform" rather than "Universal", URIs are much more universal than they are commonly perceived. URIs are not limited to the well known things like HTTP or FTP. You can express much more things, especially if one does not associate the path structure with file system path structures (which is the most common mistake people make). To be honest, I can't think of any use case that cannot be expressed using URIs. Do you have some examples? Cheers, Michel
I'll pass on the x86 and URI questions. Michel Drescher wrote:
Hi,
first, thanks for the "dirty work" to all of the editors. Next, my comments on the last issues inlined below:
On 3 Jun 2005, at 11:22, Donal K. Fellows wrote:
:
Resources Element Definition (5.4.1.1) Do we need to say anything about what it means to satisfy the whole set of elements? (I think we just need to say that the Resources element is satisfied when all of its contained resource requirements are satisfied.)
Yes, I would support this logical AND semantics.
This is fine.
Do we need to say anything about what happens when you have both Total and Individual elements? (I think not...)
Well, both have to be satisfied, otherwise the whole Resources element will not be satisfied. So I'd recommend mentioning this.
What I had in mind here was saying that both Individual and Total elements may appear in the same Resources element. If Individual and Total elements of the same type appear together then the relation Individual_Y x TotalResourcesCount = Total_Y must hold. -- Andreas Savva Fujitsu Laboratories Ltd
Do we need to say anything about what happens when you have both Total and Individual elements? (I think not...) Well, both have to be satisfied, otherwise the whole Resources element will not be satisfied. So I'd recommend mentioning this.
What I had in mind here was saying that both Individual and Total elements may appear in the same Resources element. If Individual and Total elements of the same type appear together then the relation Individual_Y x TotalResourcesCount = Total_Y must hold.
Yes, that's it. Thanks. Cheers, Michel
Andreas Savva wrote:
What I had in mind here was saying that both Individual and Total elements may appear in the same Resources element. If Individual and Total elements of the same type appear together then the relation Individual_Y x TotalResourcesCount = Total_Y must hold.
I'd agree, except we don't have numbers. We have jsdl:RangeValueType which makes everything much more complicated. In any case, I don't think that we need to *explicitly* say anything about this; it's covered by the semantics of the individual resource elements and the general composition rule. Donal.
Ah, yes, ranges... Donal K. Fellows wrote:
Andreas Savva wrote:
What I had in mind here was saying that both Individual and Total elements may appear in the same Resources element. If Individual and Total elements of the same type appear together then the relation Individual_Y x TotalResourcesCount = Total_Y must hold.
I'd agree, except we don't have numbers. We have jsdl:RangeValueType which makes everything much more complicated. In any case, I don't think that we need to *explicitly* say anything about this; it's covered by the semantics of the individual resource elements and the general composition rule.
Donal.
-- Andreas Savva Fujitsu Laboratories Ltd
I agree. The semantics for each constraint should be clear and the overall semantics is that all the constraints must be satisifed. This may lead to an empty set of possible solutions if the JSDL document is inconsistently/over constrained, but that is the submitter's problem... karl
Donal K. Fellows wrote:
I'd agree, except we don't have numbers. We have jsdl:RangeValueType which makes everything much more complicated. In any case, I don't think that we need to *explicitly* say anything about this; it's covered by the semantics of the individual resource elements and the general composition rule.
Donal.
-- Karl Czajkowski karlcz@univa.com
Michel Drescher wrote:
I think it should be "1". Although the "U" in URI stands for "Uniform" rather than "Universal", URIs are much more universal than they are commonly perceived. URIs are not limited to the well known things like HTTP or FTP. You can express much more things, especially if one does not associate the path structure with file system path structures (which is the most common mistake people make). To be honest, I can't think of any use case that cannot be expressed using URIs. Do you have some examples?
It's not that the content cannot be encoded as a URI, but whether people will want to. But in specific, you can bet that people will want to put both WSRF EndPoint References and WS-Names in, and IIRC some of those are expressed as XML document fragments? I could also think of people (especially from the Data community) wanting to put much richer things inside the Source and Target, and I'd imagine that some of them would resent having to force the descriptions of what to talk to into a URI... Donal.
On 3 Jun 2005, at 15:32, Donal K. Fellows wrote:
Michel Drescher wrote:
I think it should be "1". Although the "U" in URI stands for "Uniform" rather than "Universal", URIs are much more universal than they are commonly perceived. URIs are not limited to the well known things like HTTP or FTP. You can express much more things, especially if one does not associate the path structure with file system path structures (which is the most common mistake people make). To be honest, I can't think of any use case that cannot be expressed using URIs. Do you have some examples?
It's not that the content cannot be encoded as a URI, but whether people will want to. But in specific, you can bet that people will want to put both WSRF EndPoint References and WS-Names in, and IIRC some of those are expressed as XML document fragments?
I could also think of people (especially from the Data community) wanting to put much richer things inside the Source and Target, and I'd imagine that some of them would resent having to force the descriptions of what to talk to into a URI...
Ok convinced. So I also opt to have the URI element as optional, and to have a xsd:any extension point in both Source and Target elements (isn't this already in there?) Cheers, Michel
Michel Drescher wrote:
Ok convinced. So I also opt to have the URI element as optional, and to have a xsd:any extension point in both Source and Target elements (isn't this already in there?)
We've got the xsd:any##other already. We just need to go to 0-1 cardinality on jsdl:URI to resolve this issue I think. Donal.
On 3/6/05 03:37, "Michel Drescher" <Michel.Drescher@uk.fujitsu.com> wrote:
On 3 Jun 2005, at 11:22, Donal K. Fellows wrote:
Processor Architectures (Table 4-2 in 4.2.2.1) Should 'x86' really be called 'ia32'? (I don't really care.)
'x86' is no doubt the more common term - to be honest, only a small faint bell is ringing for ia32, and I am really not sure if this term really exists. All tools, programs and descriptions I know (i.e. the GNU tools collection) do all use x86 and ia64 to separate 32 bit and 64 bit architectures.
Should we also add the (ever so popular) x86_64 to the ProcessorArchitectureEnumeration? ia64 really only describes Itanium. -- Chris
This is a simple list folks - all we need to make sure is that we clearly define what each item means. So come one come all! Some ideas for defs: x86 : Intel Based architecture derived from the 8086 chip set x86_32 : an x86 processor capable of 32bit processing mode x86_64 : an x86 processor capable of 64bit processing mode ia64 : The Intel architecture 64bit processor steve.. Christopher Smith wrote:
On 3/6/05 03:37, "Michel Drescher" <Michel.Drescher@uk.fujitsu.com> wrote:
On 3 Jun 2005, at 11:22, Donal K. Fellows wrote:
Processor Architectures (Table 4-2 in 4.2.2.1) Should 'x86' really be called 'ia32'? (I don't really care.)
'x86' is no doubt the more common term - to be honest, only a small faint bell is ringing for ia32, and I am really not sure if this term really exists. All tools, programs and descriptions I know (i.e. the GNU tools collection) do all use x86 and ia64 to separate 32 bit and 64 bit architectures.
Should we also add the (ever so popular) x86_64 to the ProcessorArchitectureEnumeration? ia64 really only describes Itanium.
-- Chris
-- -- ------------------------------------------------------------------------ Dr A. Stephen McGough http://www.doc.ic.ac.uk/~asm ------------------------------------------------------------------------ Technical Coordinator, London e-Science Centre, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8409 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------
Since there were no objections to Steve's proposal I'll assume we closed this issue and update the spec. accordingly. Andrew Stephen McGough wrote:
This is a simple list folks - all we need to make sure is that we clearly define what each item means. So come one come all!
Some ideas for defs:
x86 : Intel Based architecture derived from the 8086 chip set x86_32 : an x86 processor capable of 32bit processing mode x86_64 : an x86 processor capable of 64bit processing mode ia64 : The Intel architecture 64bit processor
steve..
Christopher Smith wrote:
On 3/6/05 03:37, "Michel Drescher" <Michel.Drescher@uk.fujitsu.com> wrote:
On 3 Jun 2005, at 11:22, Donal K. Fellows wrote:
Processor Architectures (Table 4-2 in 4.2.2.1) Should 'x86' really be called 'ia32'? (I don't really care.)
'x86' is no doubt the more common term - to be honest, only a small faint bell is ringing for ia32, and I am really not sure if this term really exists. All tools, programs and descriptions I know (i.e. the GNU tools collection) do all use x86 and ia64 to separate 32 bit and 64 bit architectures.
Should we also add the (ever so popular) x86_64 to the ProcessorArchitectureEnumeration? ia64 really only describes Itanium.
-- Chris
-- -- ------------------------------------------------------------------------ Dr A. Stephen McGough http://www.doc.ic.ac.uk/~asm ------------------------------------------------------------------------ Technical Coordinator, London e-Science Centre, Imperial College London, Department of Computing, 180 Queen's Gate, London SW7 2BZ, UK tel: +44 (0)207-594-8409 fax: +44 (0)207-581-8024 ------------------------------------------------------------------------ Assistant Warden, West Wing, Beit Hall, Imperial College, Prince Consort Road, London, SW7 2BB tel: +44 (0)207-594-9910 ------------------------------------------------------------------------
-- Andreas Savva Fujitsu Laboratories Ltd
participants (6)
-
Andreas Savva -
Andrew Stephen McGough -
Christopher Smith -
Donal K. Fellows -
Karl Czajkowski -
Michel Drescher